Verify the account identifiers (individuals, groups, roles, and devices) are disabled after $var_account_disable_inactivity or less days of inactivity by checking the account inactivity value with the following command:
grep 'inactive\|pam_unix' /etc/pam.d/password-auth | grep -w auth auth required pam_lastlog.so inactive=35 auth sufficient pam_unix.soThe line with the inactive parameter should be placed before pam_unix.so module as in the example output.
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.
Verify the account identifiers (individuals, groups, roles, and devices) are disabled after $var_account_disable_inactivity or less days of inactivity by checking the account inactivity value with the following command:
grep 'inactive\|pam_unix' /etc/pam.d/password-auth | grep -w auth auth required pam_lastlog.so inactive=35 auth sufficient pam_unix.soThe line with the inactive parameter should be placed before pam_unix.so module as in the example output.
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.
To specify the number of days after a password expires (which signifies inactivity) until an account is permanently disabled, add or correct the following line in /etc/default/useradd:
INACTIVE=$var_account_disable_post_pw_expirationIf a password is currently on the verge of expiration, then $var_account_disable_post_pw_expiration day(s) remain(s) until the account is automatically disabled. However, if the password will not expire for another 60 days, then 60 days plus $var_account_disable_post_pw_expiration day(s) could elapse until the account would be automatically disabled. See the useradd man page for more information.
Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system. Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained.
Emergency accounts are privileged accounts that are established in response to crisis situations where the need for rapid account activation is required. Therefore, emergency account activation may bypass normal account authorization processes. If these accounts are automatically disabled, system maintenance during emergencies may not be possible, thus adversely affecting system availability. Check to see if an emergency administrator account password or account expires with the following command:
# sudo chage -l [Emergency_Administrator] Password expires:neverIf Password expires or Account expires is set to anything other than never, this is a finding.
Emergency accounts are different from infrequently used accounts (i.e., local logon accounts used by the organization's system administrators when network or normal logon/access is not available). Infrequently used accounts are not subject to automatic termination dates. Emergency accounts are accounts created in response to crisis situations, usually for use by maintenance personnel. The automatic expiration or disabling time period may be extended as needed until the crisis is resolved; however, it must not be extended indefinitely. A permanent account should be established for privileged users who need long-term maintenance accounts. To address access requirements the SUSE operating system can be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.
Emergency accounts are privileged accounts established in response to crisis situations where the need for rapid account activation is required. In the event emergency accounts are required, configure the system to terminate them after a documented time period. For every emergency account, run the following command to set an expiration date on it, substituting ACCOUNT_NAME and YYYY-MM-DD appropriately:
$ sudo chage -E YYYY-MM-DD ACCOUNT_NAMEYYYY-MM-DD indicates the documented expiration date for the account. For U.S. Government systems, the operating system must be configured to automatically terminate these types of accounts after a period of 72 hours.
If emergency user accounts remain active when no longer needed or for
an excessive period, these accounts may be used to gain unauthorized access.
To mitigate this risk, automated termination of all emergency accounts
must be set upon account creation.
The pam_faillock.so module must be loaded in preauth in /etc/pam.d/password-auth.
If the pam_faillock.so module is not loaded the system will not correctly lockout accounts to prevent password guessing attacks.
The pam_faillock.so module must be loaded in preauth in /etc/pam.d/system-auth.
If the pam_faillock.so module is not loaded the system will not correctly lockout accounts to prevent password guessing attacks.
The dir configuration option in PAM pam_faillock.so module defines where the lockout records is stored. The configured directory must have the correct SELinux context.
Not having the correct SELinux context on the pam_faillock.so records directory may lead to unauthorized access to the directory.
PAM faillock locks an account due to excessive password failures, this event must be logged.
Without auditing of these events it may be harder or impossible to identify what an attacker did after an attack.
By setting a `dir` in the faillock configuration account lockouts will persist across reboots.
Having lockouts persist across reboots ensures that account is only unlocked by an administrator. If the lockouts did not persist across reboots an attack could simply reboot the system to continue brute force attacks against the accounts on the system.
Temporary accounts are established as part of normal account activation procedures when there is a need for short-term accounts. In the event temporary accounts are required, configure the system to terminate them after a documented time period. For every temporary account, run the following command to set an expiration date on it, substituting USER and YYYY-MM-DD appropriately:
$ sudo chage -E YYYY-MM-DD USERYYYY-MM-DD indicates the documented expiration date for the account. For U.S. Government systems, the operating system must be configured to automatically terminate these types of accounts after a period of 72 hours.
If temporary user accounts remain active when no longer needed or for
an excessive period, these accounts may be used to gain unauthorized access.
To mitigate this risk, automated termination of all temporary accounts
must be set upon account creation.
Change user IDs (UIDs), or delete accounts, so each has a unique name.
To assure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system.
Ensure accounts on the system have unique names. To ensure all accounts have unique names, run the following command:
$ sudo getent passwd | awk -F: '{ print $1}' | uniq -d
If a username is returned, change or delete the username.
Unique usernames allow for accountability on the system.
Implement an automated system for managing user accounts that minimizes the risk of errors, either intentional or deliberate. This system should integrate with an existing enterprise user management system, such as one based on Identity Management tools such as Active Directory, Kerberos, Directory Server, etc.
A comprehensive account management process that includes automation helps to ensure the accounts designated as requiring attention are consistently and promptly addressed. Enterprise environments make user account management challenging and complex. A user management process requiring administrators to manually address account management functions adds risk of potential oversight.
All local interactive user accounts, upon creation, should be assigned a home directory.
Configure the operating system to assign home directories to all new local interactive users by setting the CREATE_HOME
parameter in /etc/login.defs to yes as follows:
CREATE_HOME yes
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.
To ensure the logon failure delay controlled by /etc/login.defs is set properly, add or correct the FAIL_DELAY setting in /etc/login.defs to read as follows:
FAIL_DELAY $var_accounts_fail_delay
Increasing the time between a failed authentication attempt and re-prompting to enter credentials helps to slow a single-threaded brute force attack.
Limiting the number of allowed users and sessions per user can limit risks related to Denial of Service attacks. This addresses concurrent sessions for a single account and does not address concurrent sessions by a single user via multiple accounts. To set the number of concurrent sessions per user add the following line in /etc/security/limits.conf or a file under /etc/security/limits.d/:
* hard maxlogins $var_accounts_max_concurrent_login_sessions
Limiting simultaneous user logins can insulate the system from denial of service problems caused by excessive logins. Automated login processes operating improperly or maliciously may result in an exceptional number of simultaneous login sessions.
To specify password maximum age for new accounts, edit the file /etc/login.defs and add or correct the following line:
PASS_MAX_DAYS $var_accounts_maximum_age_login_defsA value of 180 days is sufficient for many environments. The DoD requirement is 60. The profile requirement is $var_accounts_maximum_age_login_defs.
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.
Setting the password maximum age ensures users are required to
periodically change their passwords. Requiring shorter password lifetimes
increases the risk of users writing down the password in a convenient
location subject to physical compromise.
To specify password minimum age for new accounts, edit the file /etc/login.defs and add or correct the following line:
PASS_MIN_DAYS $var_accounts_minimum_age_login_defsA value of 1 day is considered sufficient for many environments. The DoD requirement is 1. The profile requirement is $var_accounts_minimum_age_login_defs.
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,
then the password could be repeatedly changed in a short period of time to
defeat the organization's policy regarding password reuse.
Setting the minimum password age protects against users cycling back to a
favorite password after satisfying the password reuse requirement.
If any account other than root has a UID of 0, this misconfiguration should
be investigated and the accounts other than root should be removed or have
their UID changed.
If the account is associated with system commands or applications the UID
should be changed to one greater than "0" but less than "1000."
Otherwise assign a UID greater than "1000" that has not already been
assigned.
An account has root authority if it has a UID of 0. Multiple accounts with a UID of 0 afford more opportunity for potential intruders to guess a password for a privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner.
If any password hashes are stored in /etc/passwd (in the second field, instead of an x or *), the cause of this misconfiguration should be investigated. The account should have its password reset and the hash should be properly stored, or the account should be deleted entirely.
The hashes for all user account passwords should be stored in the file /etc/shadow and never in /etc/passwd, which is readable by all users.
Verify the operating system requires the shadow password suite configuration be set to encrypt interactive user passwords using a strong cryptographic hash. Check that the interactive user account passwords are using a strong password hash with the following command:
$ sudo cut -d: -f2 /etc/shadow $6$kcOnRq/5$NUEYPuyL.wghQwWssXRcLRFiiru7f5JPV6GaJhNC2aK5F3PZpE/BCCtwrxRc/AInKMNX3CdMw11m9STiql12f/Password hashes ! or * indicate inactive accounts not available for logon and are not evaluated. If any interactive user password hash does not begin with $6, this is a finding.
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.
All users should have a password change date in the past.
If a user recorded password change date is in the future then they could bypass any set password expiration.
To specify password length requirements for new accounts, edit the file /etc/login.defs and add or correct the following line:
PASS_MIN_LEN $var_accounts_password_minlen_login_defs
Requiring a minimum password length makes password cracking attacks more difficult by ensuring a larger search space. However, any security benefit from an onerous requirement must be carefully weighed against usability problems, support costs, or counterproductive behavior that may result.
The pam_pwquality module's dcredit parameter controls requirements for usage of digits in a password. When set to a negative number, any password will be required to contain that many digits. When set to a positive number, pam_pwquality will grant +1 additional length credit for each digit. Modify the dcredit setting in /etc/security/pwquality.conf to require the use of a digit in passwords.
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.
Requiring digits makes password guessing attacks more difficult by ensuring a larger
search space.
The pam_pwquality module's dictcheck check if passwords contains dictionary words. When dictcheck is set to 1 passwords will be checked for dictionary words.
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.
Passwords with dictionary words may be more vulnerable to password-guessing attacks.
The pam_pwquality module's difok parameter sets the number of characters
in a password that must not be present in and old password during a password change.
Modify the difok setting in /etc/security/pwquality.conf
to equal $var_password_pam_difok to require differing characters
when changing passwords.
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.
Requiring a minimum number of different characters during password changes ensures that
newly changed passwords should not resemble previously compromised ones.
Note that passwords which are changed on compromised systems will still be compromised, however.
The pam_pwquality module's local_users_only parameter controls requirements for enforcing password complexity by pam_pwquality only for local user accounts and ignoring centralized user account management password complexity configurations. Enable the local_users_only setting in /etc/security/pwquality.conf to require password complexity enforcement for only local user accounts.
The operating system must provide automated mechanisms for supporting account management functions. Enterprise environments make application account management challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error.
The pam_pwquality module's enforce_for_root parameter controls requirements for enforcing password complexity for the root user. Enable the enforce_for_root setting in /etc/security/pwquality.conf to require the root user to use complex passwords.
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.
Verify that the operating system uses "pwquality" to enforce the password complexity rules. Verify the pwquality module is being enforced by operating system by running the following command:
$ grep -i enforcing /etc/security/pwquality.conf enforcing = 1If the value of "enforcing" is not "1" or the line is commented out, this is a finding.
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. Using enforcing=1 ensures "pwquality" enforces complex password construction configuration and has the ability to limit brute-force attacks on the system.
The pam_pwquality module's lcredit parameter controls requirements for usage of lowercase letters in a password. When set to a negative number, any password will be required to contain that many lowercase characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each lowercase character. Modify the lcredit setting in /etc/security/pwquality.conf to require the use of a lowercase character in passwords.
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
possble combinations that need to be tested before the password is compromised.
Requiring a minimum number of lowercase characters makes password guessing attacks
more difficult by ensuring a larger search space.
The pam_pwquality module's maxclassrepeat parameter controls requirements for consecutive repeating characters from the same character class. When set to a positive number, it will reject passwords which contain more than that number of consecutive characters from the same character class. Modify the maxclassrepeat setting in /etc/security/pwquality.conf to equal $var_password_pam_maxclassrepeat to prevent a run of ($var_password_pam_maxclassrepeat + 1) or more identical characters.
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 a password, the greater the number of possible combinations that need to be tested before the
password is compromised.
The pam_pwquality module's maxrepeat parameter controls requirements for consecutive repeating characters. When set to a positive number, it will reject passwords which contain more than that number of consecutive characters. Modify the maxrepeat setting in /etc/security/pwquality.conf to equal $var_password_pam_maxrepeat to prevent a run of ($var_password_pam_maxrepeat + 1) or more identical characters.
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.
Passwords with excessive repeating characters may be more vulnerable to password-guessing attacks.
The pam_pwquality module's minclass parameter controls requirements for usage of different character classes, or types, of character that must exist in a password before it is considered valid. For example, setting this value to three (3) requires that any password must have characters from at least three different categories in order to be approved. The default value is zero (0), meaning there are no required classes. There are four categories available:
* Upper-case characters * Lower-case characters * Digits * Special characters (for example, punctuation)Modify the minclass setting in /etc/security/pwquality.conf entry to require $var_password_pam_minclass differing categories of characters when changing passwords.
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.
Requiring a minimum number of character categories makes password guessing attacks more difficult
by ensuring a larger search space.
The pam_pwquality module's minlen parameter controls requirements for minimum characters required in a password. Add minlen=$var_password_pam_minlen after pam_pwquality to set minimum password length requirements.
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.
The pam_pwquality module's ocredit= parameter controls requirements for usage of special (or "other") characters in a password. When set to a negative number, any password will be required to contain that many special characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each special character. Modify the ocredit setting in /etc/security/pwquality.conf to equal $var_password_pam_ocredit to require use of a special character in passwords.
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.
Requiring a minimum number of special characters makes password guessing attacks
more difficult by ensuring a larger search space.
Do not allow users to reuse recent passwords. This can be
accomplished by using the remember option for the
pam_pwhistory PAM modules.
In the file /etc/pam.d/common-password, make sure the parameters
remember and use_authtok are present, and that the value
for the remember parameter is $var_password_pam_remember or greater. For example:
password requisite pam_pwhistory.so ...existing_options... remember=$var_password_pam_remember use_authtokThe DoD STIG requirement is 5 passwords.
Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user.
Do not allow users to reuse recent passwords. This can be accomplished by using the
remember option for the pam_pwhistory PAM module.
On systems with newer versions of authselect, the pam_pwhistory PAM module
can be enabled via authselect feature:
authselect enable-feature with-pwhistoryOtherwise, it should be enabled using an authselect custom profile.
Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user.
Do not allow users to reuse recent passwords. This can be accomplished by using the
remember option for the pam_pwhistory PAM module.
On systems with newer versions of authselect, the pam_pwhistory PAM module
can be enabled via authselect feature:
authselect enable-feature with-pwhistoryOtherwise, it should be enabled using an authselect custom profile.
Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user.
To enable PAM password complexity in password-auth file: Edit the password section in /etc/pam.d/password-auth to show password requisite pam_pwquality.so.
Enabling PAM password complexity permits to enforce strong passwords and consequently makes the system less prone to dictionary attacks.
To enable PAM password complexity in system-auth file: Edit the password section in /etc/pam.d/system-auth to show password requisite pam_pwquality.so.
Enabling PAM password complexity permits to enforce strong passwords and consequently makes the system less prone to dictionary attacks.
To configure the number of retry prompts that are permitted per-session: Edit the pam_pwquality.so statement in /etc/pam.d/system-auth to show retry=$var_password_pam_retry, or a lower value if site policy is more restrictive. The DoD requirement is a maximum of 3 prompts per session.
Setting the password retry prompts that are permitted on a per-session basis to a low value requires some software, such as SSH, to re-connect. This can slow down and draw additional attention to some types of password-guessing attacks. Note that this is different from account lockout, which is provided by the pam_faillock module.
The pam_pwquality module's ucredit= parameter controls requirements for usage of uppercase letters in a password. When set to a negative number, any password will be required to contain that many uppercase characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each uppercase character. Modify the ucredit setting in /etc/security/pwquality.conf to require the use of an uppercase character in passwords.
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.
Do not allow users to reuse recent passwords. This can be accomplished by using the remember option for the pam_unix or pam_pwhistory PAM modules.
Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user.
Configure the number or rounds for the password hashing algorithm. This can be
accomplished by using the rounds option for the pam_unix PAM module.
In file /etc/pam.d/password-auth append rounds=$var_password_pam_unix_rounds
to the pam_unix.so entry, as shown below:
password sufficient pam_unix.so ...existing_options... rounds=$var_password_pam_unix_roundsThe system's default number of rounds is 5000.
Using a higher number of rounds makes password cracking attacks more difficult.
Configure the number or rounds for the password hashing algorithm. This can be
accomplished by using the rounds option for the pam_unix PAM module.
In file /etc/pam.d/system-auth append rounds=$var_password_pam_unix_rounds
to the pam_unix.so entry, as shown below:
password sufficient pam_unix.so ...existing_options... rounds=$var_password_pam_unix_roundsThe system's default number of rounds is 5000.
Using a higher number of rounds makes password cracking attacks more difficult.
Configure non-compliant accounts to enforce a $var_accounts_maximum_age_login_defs-day maximum password lifetime restriction by running the following command:
$ sudo chage -M $var_accounts_maximum_age_login_defs USER
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.
Configure the root account to enforce a $var_accounts_maximum_age_root-day maximum password lifetime restriction by running the following command:
$ sudo chage -M $var_accounts_maximum_age_root root
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.
Configure non-compliant accounts to enforce a 24 hours/1 day minimum password lifetime by running the following command:
$ sudo chage -m 1 USER
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.
To configure how many days prior to password expiration that a warning will be issued to users, run the command:
$ sudo chage --warndays $var_accounts_password_warn_age_login_defs USERThe DoD requirement is 7, and CIS recommendation is no less than 7 days. This profile requirement is $var_accounts_password_warn_age_login_defs.
Providing an advance warning that a password will be expiring gives users time to think of a secure password. Users caught unaware may choose a simple password or write it down where it may be discovered.
To specify how many days prior to password expiration that a warning will be issued to users, edit the file /etc/login.defs and add or correct the following line:
PASS_WARN_AGE $var_accounts_password_warn_age_login_defsThe DoD requirement is 7. The profile requirement is $var_accounts_password_warn_age_login_defs.
Setting the password warning age enables users to make the change at a practical time.
To configure the system to introduce a delay after failed logon attempts, add or correct the pam_faildelay settings in /etc/pam.d/common-auth to make sure its delay parameter is at least $var_password_pam_delay or greater. For example:
auth required pam_faildelay.so delay=$var_password_pam_delay
Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.
PAM faillock locks an account due to excessive password failures, this event must be logged.
Without auditing of these events it may be harder or impossible to identify what an attacker did after an attack.
This rule configures the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so. pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. Ensure that the file /etc/security/faillock.conf contains the following entry: deny = <count> Where count should be less than or equal to $var_accounts_passwords_pam_faillock_deny and greater than 0. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version.
By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking the account.
This rule configures the system to lock out the root account after a number of incorrect login attempts using pam_faillock.so. pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version.
By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking the account.
This rule ensures that the system lock out accounts using pam_faillock.so persist after system reboot. From "pam_faillock" man pages:
Note that the default directory that "pam_faillock" uses is usually cleared on system boot so the access will be reenabled after system reboot. If that is undesirable, a different tally directory must be set with the "dir" option.pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version. The chosen profile expects the directory to be $var_accounts_passwords_pam_faillock_dir.
Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks. In combination with the silent option, user enumeration attacks are also mitigated.
The pam_faillock module's local_users_only parameter controls requirements for enforcing failed lockout attempts only for local user accounts and ignoring centralized user account management failed attempt configurations.
The operating system must provide automated mechanisms for supporting account management functions. Enterprise environments make application account management challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error. Locking out remote accounts may cause unintentional DoS.
Utilizing pam_faillock.so, the fail_interval directive configures the system to lock out an account after a number of incorrect login attempts within a specified time period. Ensure that the file /etc/security/faillock.conf contains the following entry: fail_interval = <interval-in-seconds> where interval-in-seconds is $var_accounts_passwords_pam_faillock_fail_interval or greater. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version.
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.
This rule ensures the system prevents informative messages from being presented to the user pertaining to logon information after a number of incorrect login attempts using pam_faillock.so. pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version.
The pam_faillock module without the silent option will leak information about the existence or non-existence of a user account in the system because the failures are not recorded for unknown users. The message about the user account being locked is never displayed for non-existing user accounts allowing the adversary to infer that a particular account exists or not on the system.
This rule configures the system to lock out accounts during a specified time period after a number of incorrect login attempts using pam_faillock.so. Ensure that the file /etc/security/faillock.conf contains the following entry: unlock_time=<interval-in-seconds> where interval-in-seconds is $var_accounts_passwords_pam_faillock_unlock_time or greater. pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. In order to avoid any errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version. If unlock_time is set to 0, manual intervention by an administrator is required to unlock a user. This should be done using the faillock tool.
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.
The Red Hat Enterprise Linux 10 operating system must lock an account after - at most - $var_password_pam_tally2 consecutive invalid access attempts.
By limiting the number of failed logon attempts, the risk of unauthorized
system access via user password guessing, otherwise known as brute-force
attacks, is reduced. Limits are imposed by locking the account.
To configure the operating system to lock an account after three
unsuccessful consecutive access attempts using pam_tally2.so,
modify the content of both /etc/pam.d/common-auth and
/etc/pam.d/common-account as follows:
auth required pam_tally2.so onerr=fail silent audit deny=$var_password_pam_tally2
account required pam_tally2.so
This rule configures the system to lock out the root account after a number of incorrect login attempts using pam_tally2.so.
By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking the account.
This rule configures the system to lock out accounts during a specified time period after a number of incorrect login attempts using pam_tally2.so.
By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking the account.
To configure polyinstantiated /tmp directories, first create the parent directories which will hold the polyinstantiation child directories. Use the following command:
$ sudo mkdir --mode 000 /tmp/tmp-instThen, add the following entry to /etc/security/namespace.conf:
/tmp /tmp/tmp-inst/ level root,adm
Polyinstantiation of temporary directories is a proactive security measure which reduces chances of attacks that are made possible by /tmp directories being world-writable.
To configure polyinstantiated /tmp directories, first create the parent directories which will hold the polyinstantiation child directories. Use the following command:
$ sudo mkdir --mode 000 /var/tmp/tmp-instThen, add the following entry to /etc/security/namespace.conf:
/var/tmp /var/tmp/tmp-inst/ level root,adm
Polyinstantiation of temporary directories is a proactive security measure which reduces chances of attacks that are made possible by /var/tmp directories being world-writable.
The root user should have a primary group of 0.
To help ensure that root-owned files are not inadvertently exposed to other users.
For each element in root's path, run:
# ls -ld DIRand ensure that write permissions are disabled for group and other.
Such entries increase the risk that root could execute code provided by unprivileged users, and potentially malicious code.
Configure user accounts that have been inactive for over a given period of time to be automatically disabled by running the following command:
$ sudo chage --inactive 30USER
Inactive accounts pose a threat to system security since the users are not logging in to notice failed login attempts or other anomalies.
Setting the TMOUT option in /etc/profile ensures that all user sessions will terminate based on inactivity. The value of TMOUT should be exported and read only. The TMOUT setting in a file loaded by /etc/profile, e.g. /etc/profile.d/tmout.sh should read as follows:
typeset -xr TMOUT=$var_accounts_tmoutor
declare -xr TMOUT=$var_accounts_tmoutUsing the
typeset keyword is preferred for wider compatibility with ksh and other shells.
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.
To ensure the default umask for users of the Bash shell is set properly, add or correct the umask setting in /etc/bashrc to read as follows:
umask $var_accounts_user_umask
The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users.
To ensure the default umask for users of the C shell is set properly, add or correct the umask setting in /etc/csh.cshrc to read as follows:
umask $var_accounts_user_umask
The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users.
To ensure the default umask controlled by /etc/login.defs is set properly, add or correct the UMASK setting in /etc/login.defs to read as follows:
UMASK $var_accounts_user_umask
The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read and written to by unauthorized users.
To ensure the default umask controlled by /etc/profile is set properly, add or correct the umask setting in /etc/profile to read as follows:
umask $var_accounts_user_umaskNote that /etc/profile also reads scrips within /etc/profile.d directory. These scripts are also valid files to set umask value. Therefore, they should also be considered during the check and properly remediated, if necessary.
The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users.
Remove the UMASK environment variable from all interactive users initialization files.
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.
Change the group owner of interactive users files to the group found in
/etc/passwdfor the user. To change the group owner of a local interactive user home directory, use the following command:
$ sudo chgrp USER_GROUP /home/USER/.INIT_FILEThis rule ensures every initialization file related to an interactive user is group-owned by an interactive user.
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.
Set the mode on files being executed by the user initialization files with the following command:
$ sudo chmod o-w FILE
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.
Set the owner of the user initialization files for interactive users to the primary owner with the following command:
$ sudo chown USER /home/USER/.*This rule ensures every initialization file related to an interactive user is owned by an interactive user.
Local initialization files are used to configure the user's shell environment upon logon. Malicious modification of these files could compromise accounts upon logon.
Ensure that all interactive user initialization files executable search path statements do not contain statements that will reference a working directory other than the users home directory.
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 users 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).
Assign home directories to all interactive users that currently do not have a home directory assigned. This rule checks if the home directory is properly defined in a folder which has at least one parent folder, like "user" in "/home/user" or "/remote/users/user". Therefore, this rule will report a finding for home directories like /users, /tmp or /.
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.
Create home directories to all local interactive users that currently do not have a home directory assigned. Use the following commands to create the user home directory assigned in /etc/passwd:
$ sudo mkdir /home/USER
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.
Change the group of a local interactive users files and directories to a group that the interactive user is a member of. To change the group owner of a local interactive users files and directories, use the following command:
$ sudo chgrp USER_GROUP /home/USER/FILE_DIRThis rule ensures every file or directory under the home directory related to an interactive user is group-owned by an interactive user.
If a local interactive users files are group-owned by a group of which the user is not a member, unintended users may be able to access them.
Either remove all files and directories from the system that do not have a valid user, or assign a valid user to all unowned files and directories. To assign a valid owner to a local interactive user's files and directories, use the following command:
$ sudo chown -R USER /home/USERThis rule ensures every file or directory under the home directory related to an interactive user is owned by an interactive user.
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.
Set the mode on files and directories in the local interactive user home directory with the following command:
$ sudo chmod 0750 /home/USER/FILE_DIRFiles that begin with a "." are excluded from this requirement.
If a local interactive user files have excessive permissions, unintended users may be able to access or modify them.
While the system administrator can establish secure permissions for users' .netrc files, the users can easily override these. This rule ensures every .netrc file or directory under the home directory related to an interactive user is not group or world accessible
.netrc files may contain unencrypted passwords that may be used to attack other systems. Note: While the complete removal of .netrc files is recommended, if any are required on the system, secure permissions must be applied.
The user home directory is space defined for the particular user to set local environment variables and to store personal files. Since the user is accountable for files stored in the user home directory, the user must be the owner of the directory.
Since the user is accountable for files stored in the user home directory, the user must be the owner of the directory.
At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F path=/usr/sbin/pam_timestamp_check -F auid>=1000 -F auid!=unset -F key=privilegedIf the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:
-a always,exit -F path=/usr/sbin/pam_timestamp_check -F auid>=1000 -F auid!=unset -F key=privileged
Misuse of privileged functions, either intentionally or unintentionally by
authorized users, or by unauthorized external entities that have compromised 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 and advanced persistent threats.
Privileged programs are subject to escalation-of-privilege attacks,
which attempt to subvert their normal role of providing some necessary but
limited capability. As such, motivation exists to monitor these programs for
unusual activity.
Red Hat Enterprise Linux 10 must be configured to prevent overwriting of custom authentication configuration settings by the authconfig utility. This can be avoided by creating new local configuration files and creating new or moving existing symbolic links to them. The authconfig utility will recognize the local configuration files and not overwrite them, while writing its own settings to the original configuration files.
When using the authconfig utility to modify authentication configuration settings, the "system-auth" and "password-auth" files and any custom settings that they may contain are overwritten.
The tmux terminal multiplexer is used to implement automatic session locking. It should be started from /etc/bashrc or drop-in files within /etc/profile.d/.
Unlike bash itself, the tmux terminal multiplexer provides a mechanism to lock sessions after period of inactivity. 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 tmux terminal multiplexer is used to implement automatic session locking. It should be started from /etc/bashrc or drop-in files within /etc/profile.d/.
Unlike bash itself, the tmux terminal multiplexer provides a mechanism to lock sessions after period of inactivity. 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 OpenSC smart card tool can auto-detect smart card drivers; however, setting the smart card drivers in use by your organization helps to prevent users from using unauthorized smart cards. The default smart card driver for this profile is $var_smartcard_drivers. To configure the OpenSC driver, edit the /etc/opensc.conf and add the following line into the file in the app default block, so it will look like:
app default {
...
card_drivers = $var_smartcard_drivers;
}
Smart card login provides two-factor authentication stronger than that provided by a username and password combination. Smart cards leverage PKI (public key infrastructure) in order to provide and verify credentials. Configuring the smart card driver in use by your organization helps to prevent users from using unauthorized smart cards.
The opensc module should be configured for use over the Coolkey PKCS#11 module in the NSS database. To configure the NSS database to use the opensc module, run the following command:
$ sudo pkcs11-switch opensc
Smart card login provides two-factor authentication stronger than that provided by a username and password combination. Smart cards leverage PKI (public key infrastructure) in order to provide and verify credentials.
To enable console screen locking in tmux terminal multiplexer after a period of inactivity, the lock-after-time option has to be set to a value greater than 0 and less than or equal to 900 in /etc/tmux.conf.
Locking the session after a period of inactivity limits the potential exposure if the session is left unattended.
To enable console screen locking in tmux terminal multiplexer, the vlock command must be configured to be used as a locking mechanism. Add the following line to /etc/tmux.conf:
set -g lock-command vlock. The console can now be locked with the following key combination:
ctrl+b :lock-session
The tmux package allows for a session lock to be implemented and configured. However, the session lock is implemented by an external command. The tmux default configuration does not contain an effective session lock.
To set a key binding for the screen locking in tmux terminal multiplexer, the session-lock command must be bound to a key. Add the following line to /etc/tmux.conf:
bind X lock-session. The console can now be locked with the following key combination:
Ctrl+b Shift+x
The tmux package allows for a session lock to be implemented and configured. However, the session lock is implemented by an external command. The tmux default configuration does not contain an effective session lock.
Red Hat Enterprise Linux 10 systems support an "interactive boot" option that can be used to prevent services from being started. On a Red Hat Enterprise Linux 10 system, interactive boot can be enabled by providing a 1, yes, true, or on value to the systemd.confirm_spawn kernel argument.
Using interactive boot, the console user could disable auditing, firewalls, or other services, weakening system security.
The pam_cracklib module's dcredit parameter controls requirements for usage of digits in a password. When set to a negative number, any password will be required to contain that many digits. When set to a positive number, pam_cracklib will grant +1 additional length credit for each digit. Add dcredit=-1 after pam_cracklib.so to require use of a digit in passwords.
Requiring digits makes password guessing attacks more difficult by ensuring a larger search space.
The pam_cracklib module's difok parameter controls requirements for usage of different characters during a password change. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different. Make sure the difok parameter for the pam_cracklib module is configured to greater than or equal to $var_password_pam_difok.
Requiring a minimum number of different characters during password changes ensures that newly changed passwords should not resemble previously compromised ones. Note that passwords which are changed on compromised systems will still be compromised, however.
The pam_cracklib module's lcredit= parameter controls requirements for usage of lowercase letters in a password. When set to a negative number, any password will be required to contain that many lowercase characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each lowercase character. Add lcredit=-1 after pam_cracklib.so to require use of a lowercase character in passwords.
Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space.
The pam_cracklib module's minlen parameter controls requirements for minimum characters required in a password. Add minlen=$var_password_pam_minlen to set minimum password length requirements.
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.
The pam_cracklib module's ocredit= parameter controls requirements for usage of special (or ``other'') characters in a password. When set to a negative number, any password will be required to contain that many special characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each special character. Make sure the ocredit parameter for the pam_cracklib module is set to less than or equal to $var_password_pam_ocredit. For example, ocredit=$var_password_pam_ocredit.
Requiring a minimum number of special characters makes password guessing attacks more difficult by ensuring a larger search space.
The pam_cracklib module's retry parameter controls the maximum number of times to prompt the user for the password before returning with error. Make sure it is configured with a value that is no more than $var_password_pam_retry. For example, retry=1.
To reduce opportunities for successful guesses and brute-force attacks.
The pam_cracklib module's ucredit= parameter controls requirements for usage of uppercase letters in a password. When set to a negative number, any password will be required to contain that many uppercase characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each uppercase character. Add ucredit=-1 after pam_cracklib.so to require use of an upper case character in passwords.
Requiring a minimum number of uppercase characters makes password guessing attacks more difficult by ensuring a larger search space.
By default, SystemD will reboot the system if the Ctrl-Alt-Del
key sequence is pressed Ctrl-Alt-Delete more than 7 times in 2 seconds.
To configure the system to ignore the CtrlAltDelBurstAction
setting, add or modify the following to /etc/systemd/system.conf:
CtrlAltDelBurstAction=none
A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot.
By default, SystemD will reboot the system if the Ctrl-Alt-Del
key sequence is pressed.
To configure the system to ignore the Ctrl-Alt-Del key sequence from the
command line instead of rebooting the system, do either of the following:
ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.targetor
systemctl mask ctrl-alt-del.target
A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot.
To disable core dumps for all users, add the following line to /etc/security/limits.conf, or to a file within the /etc/security/limits.d/ directory:
* hard core 0
A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems.
Verify the operating system is not configured to bypass password requirements for privilege escalation. Check the configuration of the "/etc/pam.d/sudo" file with the following command:
$ sudo grep pam_succeed_if /etc/pam.d/sudoIf any occurrences of "pam_succeed_if" is returned from the command, this is a finding.
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.
To configure the system to notify users of last logon/access using pam_lastlog, add or correct the pam_lastlog settings in /etc/pam.d/postlogin to include showfailed option, such as:
session [default=1] pam_lastlog.so showfailedAnd make sure that the silent option is not set for this specific line.
Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.
Configure user authentication setup to use the authselect tool. If authselect profile is selected, the rule will enable the $var_authselect_profile profile.
Authselect is a successor to authconfig. It is a tool to select system authentication and identity sources from a list of supported profiles instead of letting the administrator manually build the PAM stack. That way, it avoids potential breakage of configuration, as it ships several tested profiles that are well tested and supported to solve different use-cases.
To setup a private namespace add the following line to /etc/pam.d/login:
session required pam_namespace.so
The pam_namespace PAM module sets up a private namespace for a session with polyinstantiated directories. A polyinstantiated directory provides a different instance of itself based on user name, or when using SELinux, user name, security context or both. The polyinstatied directories can be used to dedicate separate temporary directories to each account.
Ensure that the group $var_pam_wheel_group_for_su referenced by var_pam_wheel_group_for_su variable and used as value for the pam_wheel.so group option exists and has no members. This empty group used by pam_wheel.so in /etc/pam.d/su ensures that no user can run commands with altered privileges through the su command.
The su program allows to run commands with a substitute user and group ID. It is commonly used to run commands as the root user. Limiting access to such command is considered a good security practice.
Single user mode is used for recovery when the system detects an issue during boot or by manual selection from the bootloader.
Requiring authentication in single user mode prevents an unauthorized user from rebooting the system into single user to gain root privileges without credentials.
The shadow group allows system programs which require access the ability to read the /etc/shadow file. No users should be assigned to the shadow group.
Any users assigned to the shadow group would be granted read access to the /etc/shadow file. If attackers can gain read access to the /etc/shadow file, they can easily run a password cracking program against the hashed passwords to break them. Other security information that is stored in the /etc/shadow file (such as expiration) could also be useful to subvert additional user accounts.
Developers and implementers can increase the assurance in security functions by employing well-defined security policy models; structured, disciplined, and rigorous hardware and software development techniques; and sound system/security engineering principles. Implementation may include isolation of memory space and libraries. The Ubuntu operating system restricts access to security functions through the use of access control mechanisms and by implementing least privilege capabilities.
Any users assigned to the sudo group would be granted administrator access to the system.
To properly set the group owner of /etc/issue, run the command:
$ sudo chgrp root /etc/issue
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.
Proper group ownership will ensure that only root user can modify the banner.
To properly set the group owner of /etc/issue.net, run the command:
$ sudo chgrp root /etc/issue.net
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.
Proper group ownership will ensure that only root user can modify the banner.
To properly set the group owner of /etc/motd, run the command:
$ sudo chgrp root /etc/motd
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.
Proper group ownership will ensure that only root user can modify the banner.
Change the group owner of interactive users home directory to the group found in /etc/passwd. To change the group owner of interactive users home directory, use the following command:
$ sudo chgrp USER_GROUP /home/USERThis rule ensures every home directory related to an interactive user is group-owned by an interactive user. It also ensures that interactive users are group-owners of one and only one home directory.
If the Group Identifier (GID) of a local interactive users home directory is not the same as the primary GID of the user, this would allow unauthorized access to the users files, and users that share the same group may not be able to access files that they legitimately should.
To properly set the group owner of /var/log/lastlog, run the command:
$ sudo chgrp root /var/log/lastlog
Unauthorized disclosure of the contents of the /var/log/lastlog file can reveal system data to attackers, thus compromising its confidentiality.
To properly set the owner of /etc/issue, run the command:
$ sudo chown root /etc/issue
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.
Proper ownership will ensure that only root user can modify the banner.
To properly set the owner of /etc/issue.net, run the command:
$ sudo chown root /etc/issue.net
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.
Proper ownership will ensure that only root user can modify the banner.
To properly set the owner of /etc/motd, run the command:
$ sudo chown root /etc/motd
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.
Proper ownership will ensure that only root user can modify the banner.
Change the owner of interactive users home directories to that correct owner. To change the owner of a interactive users home directory, use the following command:
$ sudo chown USER /home/USERThis rule ensures every home directory related to an interactive user is owned by an interactive user. It also ensures that interactive users are owners of one and only one home directory.
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.
To properly set the owner of /usr/bin/lastlog, run the command:
$ sudo chown root /usr/bin/lastlog
Unauthorized disclosure of the contents of the /var/log/lastlog file can reveal system data to attackers, thus compromising its confidentiality.
Set the mode of the user initialization files to 0740 with the following command:
$ sudo chmod 0740 /home/USER/.INIT_FILE
Local initialization files are used to configure the user's shell environment upon logon. Malicious modification of these files could compromise accounts upon logon.
Set the mode of the user initialization files, including the root user, to 0740 with the following commands:
$ sudo chmod 0740 /root/.INIT_FILE $ sudo chmod 0740 /home/USER/.INIT_FILE
Local initialization files are used to configure the user's shell environment upon logon. Malicious modification of these files could compromise accounts upon logon.
To properly set the permissions of /etc/issue, run the command:
$ sudo chmod 0644 /etc/issue
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.
Proper permissions will ensure that only root user can modify the banner.
To properly set the permissions of /etc/issue.net, run the command:
$ sudo chmod 0644 /etc/issue.net
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.
Proper permissions will ensure that only root user can modify the banner.
To properly set the permissions of /etc/motd, run the command:
$ sudo chmod 0644 /etc/motd
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.
Proper permissions will ensure that only root user can modify the banner.
Change the mode of interactive users home directories to 0750. To change the mode of interactive users home directory, use the following command:
$ sudo chmod 0750 /home/USER
Excessive permissions on local interactive user home directories may allow unauthorized access to user files by other users.
For each human user of the system, view the permissions of the user's home directory:
# ls -ld /home/USEREnsure that the directory is not group-writable and that it is not world-readable. If necessary, repair the permissions:
# chmod g-w /home/USER # chmod o-rwx /home/USER
User home directories contain many configuration files which affect the behavior of a user's account. No user should ever have write permission to another user's home directory. Group shared directories can be configured in sub-directories or elsewhere in the filesystem if they are needed. Typically, user home directories should not be world-readable, as it would disclose file names to other users. If a subset of users need read access to one another's home directories, this can be provided using groups or ACLs.
To properly set the permissions of /usr/bin/lastlog, run the command:
$ sudo chmod 0750 /usr/bin/lastlog
Unauthorized disclosure of the contents of the /var/log/lastlog file can reveal system data to attackers, thus compromising its confidentiality.
The OpenSC smart card middleware can auto-detect smart card drivers; however by forcing the smart card driver in use by your organization, opensc will no longer autodetect or use other drivers unless specified. This helps to prevent users from using unauthorized smart cards. The default smart card driver for this profile is $var_smartcard_drivers. To force the OpenSC driver, edit the /etc/opensc.conf. Look for a line similar to:
# force_card_driver = customcos;and change it to:
force_card_driver = $var_smartcard_drivers;
Smart card login provides two-factor authentication stronger than that provided by a username and password combination. Smart cards leverage PKI (public key infrastructure) in order to provide and verify credentials. Forcing the smart card driver in use by your organization helps to prevent users from using unauthorized smart cards.
Add a group to the system for each GID referenced without a corresponding group.
If a user is assigned the Group Identifier (GID) of a group not existing on the system, and a group with the Group Identifier (GID) is subsequently created, the user may have unintended rights to any files associated with the group.
Change the group name or delete groups, so each has a unique id.
To assure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system.
Change the group name or delete groups, so each has a unique name.
To assure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system.
Red Hat Enterprise Linux 10 systems support an "interactive boot" option that can be used to prevent services from being started. On a Red Hat Enterprise Linux 10 system, interactive boot can be enabled by providing a 1, yes, true, or on value to the systemd.confirm_spawn kernel argument in /etc/default/grub. Remove any instance of
systemd.confirm_spawn=(1|yes|true|on)from the kernel arguments in that file to disable interactive boot. Recovery booting must also be disabled. Confirm that GRUB_DISABLE_RECOVERY=true is set in /etc/default/grub. It is also required to change the runtime configuration, run:
/sbin/grubby --update-kernel=ALL --remove-args="systemd.confirm_spawn"
grub2-mkconfig -o /boot/grub2/grub.cfg
Using interactive or recovery boot, the console user could disable auditing, firewalls, or other services, weakening system security.
Display of a standardized and approved use notification before granting access to the SUSE operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.
The banner must be acknowledged by the user prior to allowing the user access to the SUSE operating system. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law.
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 the SUSE operating system:
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.Check the configuration by running the following command:
# more /etc/gdm/XsessionThe beginning of the file must contain the following text immediately after #!/bin/sh:
if ! zenity --text-info \ --title "Consent" \ --filename=/etc/gdm/banner \ --no-markup \ --checkbox="Accept." 10 10; then sleep 1; exit 1; fi
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.
For U.S. Government systems, system use notifications are required only for access via login interfaces
with human users and are not required when such human interfaces do not exist.
Configure the operating system to implement multifactor authentication by
installing the required package with the following command:
The openssl-pkcs11 package can be installed with the following command:
$ sudo dnf install openssl-pkcs11
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.
To configure logind service to terminate inactive user sessions after $var_logind_session_timeout seconds, edit the file /etc/systemd/logind.conf. Ensure that there is a section
[Login]which contains the configuration
StopIdleSessionSec=$var_logind_session_timeout.
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 let unattended.
To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to login to. If the file does not exist at all, the root user can login through any communication device on the system, whether via the console or via a raw network interface. This is dangerous as user can login to the system as root via Telnet, which sends the password in plain text over the network. By default, Red Hat Enterprise Linux 10's /etc/securetty file only allows the root user to login at the console physically attached to the system. To prevent root from logging in, remove the contents of this file. To prevent direct root logins, remove the contents of this file by typing the following command:
$ sudo echo > /etc/securetty
Disabling direct root logins ensures proper accountability and multifactor authentication to privileged accounts. Users will first login, then escalate to privileged (root) access via su / sudo. This is required for FISMA Low and FISMA Moderate systems.
Although the useradd program will not let you create a duplicate User ID (UID), it is possible for an administrator to manually edit the /etc/passwd file and change the UID field. Users must be assigned unique UIDs for accountability and to ensure appropriate access protections.
Users must be assigned unique UIDs for accountability and to ensure appropriate access protections.
If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok in /etc/pam.d/system-auth and /etc/pam.d/password-auth to prevent logins with empty passwords.
If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.
Check the "/etc/shadow" file for blank passwords with the following command:
$ sudo awk -F: '!$2 {print $1}' /etc/shadow
If the command returns any results, this is a finding.
Configure all accounts on the system to have a password or lock
the account with the following commands:
Perform a password reset:
$ sudo passwd [username]Lock an account:
$ sudo passwd -l [username]
If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.
The .forward file specifies an email address to forward the user's mail to.
Use of the .forward file poses a security risk in that sensitive data may be inadvertently transferred outside the organization. The .forward file also poses a risk as it can be used to execute commands that may perform unintended actions.
The + character in /etc/group file marks a place where entries from a network information service (NIS) should be directly inserted.
Using this method to include entries into /etc/group is considered legacy and should be avoided. These entries may provide a way for an attacker to gain access to the system.
The + character in /etc/passwd file marks a place where entries from a network information service (NIS) should be directly inserted.
Using this method to include entries into /etc/passwd is considered legacy and should be avoided. These entries may provide a way for an attacker to gain access to the system.
The + character in /etc/shadow file marks a place where entries from a network information service (NIS) should be directly inserted.
Using this method to include entries into /etc/shadow is considered legacy and should be avoided. These entries may provide a way for an attacker to gain access to the system.
The .netrc files contain login information used to auto-login into FTP servers and reside in the user's home directory. These files may contain unencrypted passwords to remote FTP servers making them susceptible to access by unauthorized users and should not be used. Any .netrc files should be removed.
Unencrypted passwords for remote FTP servers may be stored in .netrc files.
Some accounts are not associated with a human user of the system, and exist to perform some
administrative functions. An attacker should not be able to log into these accounts.
System accounts are those user accounts with a user ID less than 1000.
If any system account other than root, halt, sync, shutdown
and nfsnobody has an unlocked password, disable it with the command:
$ sudo usermod -L account
Disabling authentication for default system accounts makes it more difficult for attackers to make use of them to compromise a system.
Enforce policy requiring administrative accounts use web browsers only for local service administration.
If a browser vulnerability is exploited while running with administrative privileges, the entire system could be compromised. Specific exceptions for local service administration should be documented in site-defined policy.
Some accounts are not associated with a human user of the system, and exist to perform some
administrative functions. Should an attacker be able to log into these accounts, they should
not be granted access to a shell.
The login shell for each local account is stored in the last field of each line in
/etc/passwd. System accounts are those user accounts with a user ID less than
1000. The user ID is stored in the third field. If any system account
other than root has a login shell, disable it with the command:
$ sudo usermod -s /sbin/nologin account
Ensuring shells are not given to system accounts upon login makes it more difficult for attackers to make use of system accounts.
The tmux terminal multiplexer is used to implement automatic session locking. It should not be listed in /etc/shells.
Not listing tmux among permitted shells prevents malicious program running as user from lowering security by disabling the screen lock.
The opensc package can be installed with the following command:
$ sudo dnf install opensc
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.
The pam_apparmor package can be installed with the following command:
$ sudo dnf install pam_apparmor
Protection of system integrity using AppArmor depends on this package being installed.
The libpwquality package can be installed with the following command:
$ sudo dnf install libpwquality
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 and has the ability to limit brute-force attacks on the system.
The pcsc-lite package can be installed with the following command:
$ sudo dnf install pcsc-lite
The pcsc-lite package must be installed if it is to be available for multifactor authentication using smartcards.
To enable console screen locking, install the screen package.
The screen package can be installed with the following command:
$ sudo dnf install screenInstruct users to begin new terminal sessions with the following command:
$ screenThe console can now be locked with the following key combination:
ctrl+a x
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 logout because of the temporary nature of the absence.
Rather than relying on the user to manually lock their operation 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.
To enable console screen locking, install the tmux package. 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. Rather than be forced to wait for a period of time to expire before the user session can be locked, Red Hat Enterprise Linux 10 needs to provide users with the ability to manually invoke a session lock so users can secure their session if it is necessary to temporarily vacate the immediate physical vicinity. Instruct users to begin new terminal sessions with the following command:
$ tmuxThe console can now be locked with the following key combination:
ctrl+b :lock-session
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 logout because of the temporary nature of the absence.
Rather than relying on the user to manually lock their operation 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 tmux package allows for a session lock to be implemented and configured.
Verify the SUSE operating system is configured to not overwrite Pluggable Authentication Modules (PAM) configuration on package changes.
pam-config is a command line utility that automatically generates a system PAM configuration as packages are installed, updated or removed from the system. pam-config removes configurations for PAM modules and parameters that it does not know about. It may render ineffective PAM configuration by the system administrator and thus impact system security.
Verify that pam is configured to use /etc/pam.d/system-auth when changing passwords. Look for the following line in /etc/pam.d/passwd:
password substack system-auth
Including system-auth from the passwd module ensures that the user must pass through the PAM configuration for system authentication as found in /etc/pam.d/system-auth when changing passwords.
Temporary passwords for Red Hat Enterprise Linux 10 operating system logons must require an immediate change to a permanent password. Verify that a policy exists that ensures when a user is created, it is creating using a method that forces a user to change their password upon their next login.
Without providing this capability, an account may be created without a password. Nonrepudiation cannot be guaranteed once an account is created if a user is not forced to change the temporary password upon initial logon. Temporary passwords are typically used to allow access when new accounts are created or passwords are changed. It is common practice for administrators to create temporary passwords for user accounts that allow the users to log on, yet force them to change the password once they have successfully authenticated.
Configure the operating system to prevent direct logins to the root account by performing the following operations:
$ sudo passwd -l root
Disabling direct root logins ensures proper accountability and multifactor authentication to privileged accounts.
Emergency mode is intended as a system recovery
method, providing a single user root access to the system
during a failed boot sequence.
By default, Emergency mode is protected by requiring a password and is set
in /usr/lib/systemd/system/emergency.service.
This prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password.
Single-user mode is intended as a system recovery
method, providing a single user root access to the system by
providing a boot option at startup.
By default, single-user mode is protected by requiring a password and is set
in /usr/lib/systemd/system/rescue.service.
This prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password.
To restrict root logins on serial ports, ensure lines of this form do not appear in /etc/securetty:
ttyS0 ttyS1
Preventing direct root login to serial port interfaces helps ensure accountability for actions taken on the systems using the root account.
Assuming root shell is bash, edit the following files:
~/.profile
~/.bashrcChange any PATH variables to the vendor default for root and remove any empty PATH entries or references to relative paths.
The root account's executable search path must be the vendor default, and must contain only absolute paths.
Ensure that none of the directories in root's path is equal to a single . character, or that it contains any instances that lead to relative path traversal, such as .. or beginning a path without the slash (/) character. Also ensure that there are no "empty" elements in the path, such as in these examples:
PATH=:/bin PATH=/bin: PATH=/bin::/sbinThese empty elements have the same effect as a single . character.
Including these entries increases the risk that root could execute code from an untrusted location.
By default, the SELinux boolean httpd_can_check_spam is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_can_check_spam SELinux boolean, run the following command:
$ sudo setsebool -P httpd_can_check_spam off
By default, the SELinux boolean httpd_mod_auth_pam is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_mod_auth_pam SELinux boolean, run the following command:
$ sudo setsebool -P httpd_mod_auth_pam off
By default, the SELinux boolean spamassassin_can_network is disabled.
If this setting is enabled, it should be disabled.
To disable the spamassassin_can_network SELinux boolean, run the following command:
$ sudo setsebool -P spamassassin_can_network off
By default, the SELinux boolean spamd_enable_home_dirs is enabled.
If this setting is disabled, it should be enabled.
To enable the spamd_enable_home_dirs SELinux boolean, run the following command:
$ sudo setsebool -P spamd_enable_home_dirs on
To restrict root logins through the (deprecated) virtual console devices, ensure lines of this form do not appear in /etc/securetty:
vc/1 vc/2 vc/3 vc/4
Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account.
SystemD's debug-shell service is intended to
diagnose SystemD related boot issues with various systemctl
commands. Once enabled and following a system reboot, the root shell
will be available on tty9 which is access by pressing
CTRL-ALT-F9. The debug-shell service should only be used
for SystemD related issues and should otherwise be disabled.
By default, the debug-shell SystemD service is already disabled.
The debug-shell service can be disabled with the following command:
$ sudo systemctl mask --now debug-shell.service
This prevents attackers with physical access from trivially bypassing security on the machine through valid troubleshooting configurations and gaining root access when the system is rebooted.
The pcscd service can be enabled with the following command:
$ sudo systemctl enable pcscd.service
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.
The PAM system service can be configured to only store encrypted
representations of passwords. In
/etc/pam.d/common-auth,
the
auth section of the file controls which PAM modules execute
during a password change. Set the pam_unix.so module in the
auth section to include the argument sha512, as shown
below:
auth required pam_unix.so sha512 other arguments...
Unapproved mechanisms used for authentication to the cryptographic module are not verified and therefore cannot be relied on to provide confidentiality or integrity, and data may be compromised. This setting ensures user and group account administration utilities are configured to store only encrypted representations of passwords. Additionally, the crypt_style configuration option ensures the use of a strong hashing algorithm that makes password cracking attacks more difficult.
In /etc/libuser.conf, add or correct the following line in its [defaults] section to ensure the system will use the SHA-512 algorithm for password hashing:
crypt_style = sha512
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 that
are encrypted with a weak algorithm are no more protected than if they are
kepy in plain text.
This setting ensures user and group account administration utilities are
configured to store only encrypted representations of passwords.
Additionally, the crypt_style configuration option ensures the use
of a strong hashing algorithm that makes password cracking attacks more
difficult.
In /etc/login.defs, add or correct the following line to ensure the system will use $var_password_hashing_algorithm as the hashing algorithm:
ENCRYPT_METHOD $var_password_hashing_algorithm
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
that are encrypted with a weak algorithm are no more protected than if they are kept in plain text.
Using a stronger hashing algorithm makes password cracking attacks more difficult.
The PAM system service can be configured to only store encrypted
representations of passwords. In
/etc/pam.d/password-auth,
the
password section of the file controls which PAM modules execute
during a password change. Set the pam_unix.so module in the
password section to include the argument sha512, as shown
below:
password sufficient pam_unix.so sha512 other arguments...
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 that
are encrypted with a weak algorithm are no more protected than if they are
kepy in plain text.
This setting ensures user and group account administration utilities are
configured to store only encrypted representations of passwords.
Additionally, the crypt_style configuration option ensures the use
of a strong hashing algorithm that makes password cracking attacks more
difficult.
The PAM system service can be configured to only store encrypted
representations of passwords. In "/etc/pam.d/system-auth", the
password section of the file controls which PAM modules execute
during a password change. Set the pam_unix.so module in the
password section to include the argument sha512, as shown
below:
password sufficient pam_unix.so sha512 other arguments...
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 that
are encrypted with a weak algorithm are no more protected than if they are
kepy in plain text.
This setting ensures user and group account administration utilities are
configured to store only encrypted representations of passwords.
Additionally, the crypt_style configuration option ensures the use
of a strong hashing algorithm that makes password cracking attacks more
difficult.
In /etc/login.defs, ensure SHA_CRYPT_MIN_ROUNDS and SHA_CRYPT_MAX_ROUNDS has the minimum value of 5000. For example:
SHA_CRYPT_MIN_ROUNDS 5000 SHA_CRYPT_MAX_ROUNDS 5000Notice that if neither are set, they already have the default value of 5000. If either is set, they must have the minimum value of 5000.
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
that are encrypted with a weak algorithm are no more protected than if
they are kept in plain text.
Using more hashing rounds makes password cracking attacks more difficult.
To enable smart card authentication, consult the documentation at:
Smart card login provides two-factor authentication stronger than that provided by a username and password combination. Smart cards leverage PKI (public key infrastructure) in order to provide and verify credentials.
Configure the operating system to do certificate status checking for PKI authentication. Modify all of the cert_policy lines in /etc/pam_pkcs11/pam_pkcs11.conf to include ca like so:
cert_policy = ca, ocsp_on, signature;
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.
Configure the operating system to do certificate status checking for PKI authentication. Modify all of the cert_policy lines in /etc/pam_pkcs11/pam_pkcs11.conf to include ocsp_on like so:
cert_policy = ca, ocsp_on, signature;
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.
Configure the operating system for PKI-based authentication to use local revocation data when unable to access the network to obtain it remotely. Modify all of the cert_policy lines in /etc/pam_pkcs11/pam_pkcs11.conf to include crl_auto or crl_offline like so:
cert_policy = ca,signature,ocsp_on,crl_auto;
Without configuring a local cache of revocation data, there is the potential to allow access to users who are no longer authorized (users with revoked certificates).
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). Check that the pam_pkcs11.so option is configured in the etc/pam.d/common-auth file with the following command:
# grep pam_pkcs11.so /etc/pam.d/common-auth auth sufficient pam_pkcs11.soFor general information about enabling smart card authentication, consult the documentation at:
Smart card login provides two-factor authentication stronger than that provided by a username and password combination. Smart cards leverage PKI (public key infrastructure) in order to provide and verify credentials. 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.
UsePAM Enables the Pluggable Authentication Module interface. If set to “yes” this will enable PAM authentication using ChallengeResponseAuthentication and PasswordAuthentication in addition to PAM account and session module processing for all authentication types. To enable PAM authentication, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
UsePAM yes
When UsePAM is set to yes, PAM runs through account and session types properly. This is important if you want to restrict access to services based off of IP, time or other factors of the account. Additionally, you can make sure users inherit certain environment variables on login or disallow access to the server.
SSSD should be configured to run SSSD pam services. To configure SSSD to known SSH hosts, add pam to services under the [sssd] section in /etc/sssd/sssd.conf. For example:
[sssd] services = sudo, autofs, pam
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.
To ensure that only users who are members of the wheel group can run commands with altered privileges through the su command, make sure that the following line exists in the file /etc/pam.d/su:
auth required pam_wheel.so use_uid
The su program allows to run commands with a substitute user and group ID. It is commonly used to run commands as the root user. Limiting access to such command is considered a good security practice.
To ensure that only users who are members of the group set in the group option of pam_wheel.so module can run commands with altered privileges through the su command, make sure that the following line exists in the file /etc/pam.d/su:
auth required pam_wheel.so use_uid group=$var_pam_wheel_group_for_su
The su program allows to run commands with a substitute user and group ID. It is commonly used to run commands as the root user. Limiting access to such command is considered a good security practice.
The operating system must map the authenticated identity to the user or group account for PKI-based authentication. Verify that use_mappers is set to pwent in /etc/pam_pkcs11/pam_pkcs11.conf file with the following command:
$ grep ^use_mappers /etc/pam_pkcs11/pam_pkcs11.conf use_mappers = pwent
Without mapping the certificate used to authenticate to the user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis.
The Red Hat Enterprise Linux 10 operating system must have vlock installed to allow for session locking.
The kbd package can be installed with the following command:
$ sudo dnf install kbd
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.