Identity Authentication + Access Control for Linux Security Reinforcement

1. Identity authentication configuration:

image.png

1.1 Creation and management of user groups:
  • Create a user group: Use the command ??groupadd ?? to create a new user group.
  • Delete a user group: Use the command ??groupdel ?? to delete a user group.
  • Modify a user group: Use the command ??groupmod ?? to modify the attributes of a user group.
1.2 User creation and management:
  • Create a user: Use the command ??useradd ?? to create a new user.
  • Set user password: Use the command ??passwd ?? to set a password for the user.
  • Delete a user: Use the command ??userdel ?? to delete a user.
  • Modify user password: Use the command ??passwd ?? to modify the user’s password.
  • Verify the configuration of users and user groups: Use the command ??id ?? to verify the user groups to which the user belongs and other attributes. For example, to check the user group and other properties of user “myuser”: ??id myuser??
1.3 Empowerment:
  • Add user to user group:
    Use the command ??usermod -aG ?? to add a user to a user group.
  • Modify file permissions: Use the command ??chmod ?? to modify the file permissions.
  • Example-1: To grant permissions to a specific user group on a specific directory, you can use the ??chown?? command combined with the ??chmod?? command to complete. Here’s one way:
  1. First, change the owner of the “data” directory to the root user and change the user group to the “wheel” user group. You can use the following command: 
    chown -R root:wheel /path/to/data
  • explain:
  • ??chown??: Command to modify the owner and user group of a file or directory.
  • ??-R??: Recursively modify all file owners and user groups in a directory and its subdirectories.
  • ??root:wheel??: Specify the new owner and user group.
  • ??/path/to/data??: The path to the target directory.
  1. Then, grant read and write permissions to the “data” directory to the “wheel” user group. The following commands can be used:
chmod -R g + rw /path/to/data

explain:

  • ??chmod??: Command to modify file or directory permissions.
  • ??-R??: Recursively modify file permissions in a directory and its subdirectories.
  • ??g + rw??: Add read and write permissions to the user group.
  • ??/path/to/data??: The path to the target directory.

In this way, change the owner of the “data” directory to the root user, change the user group to the “wheel” user group, and then grant the “wheel” user group read and write permissions to the directory.

1.4 Prohibits illegal su privilege escalation

Check whether the PAM authentication module is used to prohibit users outside the wheel group from being su as root.

Check Steps

Execute the command cat /etc/pam.d/su,

Check whether the following configuration exists in the file: auth sufficient pam_rootok.so auth required pam_wheel.so group=wheel Compliance standard Only users in the wheel group are allowed to su as root, otherwise it is compliant, otherwise it is not compliant.

Reinforcement plan

1. Edit the file /etc/pam.d/su and add the following two lines at the beginning of the file (modify if there is any, add if not):

auth sufficient pam_rootok.so auth required pam_wheel.so use_uid #Note that auth and sufficient are separated by two tabs, and sufficient is separated from the dynamic library path by a tab. Note: (This indicates that only users in the wheel group You can use the su command to become the root user. You can add the user to the wheel group so that it can use the su command to become the root user.) Add method:

#usermod -G wheel username #username is the account name that needs to be added to the wheel group.
2. Access control and password security policy configuration:

image.png

2.1 Empty password policy:
  • Prohibit empty passwords: Ensure that all users have passwords and do not allow empty passwords.
  • Rationale: All accounts must have a password to prevent the account from being used by unauthorized users.
  • Check steps: Execute the following command to check whether there is an account with an empty password in the system
#/bin/cat /etc/shadow | /bin/awk -F: '($2 == "" ) { print "user " $1 " does not have a password "}\ '
  • Compliance standards: Accounts that do not have empty passwords are compliant, otherwise they are not compliant.
2.2 Password validity period policy:
  • Set the password validity period: Use the command chage -M to set the maximum number of days the password is valid.
  • Set password expiration warning: Use the command chage -W to set the number of warning days before password expiration. OR
  • Check whether the number of warning days before password expiration is set. Detection steps: View the file /etc/login.defs and check whether the following parameter values meet the requirements: PASS_WARN_AGE Compliance standard: PASS_WARN_AGE equals 7 Heaven is compliant, otherwise it is not. Reinforcement plan: 1. Perform backup:
#cp -p /etc/login.defs /etc/login.defs_bak
  • 2. Modify the policy settings, edit the file /etc/login.defs, and add the following content to the file (modify if it exists, add if it does not exist):
PASS_WARN_AGE 7
2.3 Password complexity policy:
  • Modify the password complexity requirement: edit the file /etc/pam.d/system-auth, find the line containing password requisite pam_pwquality.so, and modify the parameters to increase Password complexity requirements.
  • Configuration requirements:
The pam_cracklib module checks password strength. It performs checks such as ensuring that the password is not a dictionary word, is of a certain length, contains a mixture of characters (like letters, numbers, other), etc.
retry= 3 - allows 3 attempts before returning failure.
minlen = 14 - Password must be 14 characters or more
dcredit = - 1 - Provide at least 1 digit
ucredit = - 1 - Provide at least one uppercase character
ocredit = - 1 - Provide at least one special character
lcredit = - 1 - Provide at least one lowercase character
The setup shown above is one possible strategy. Change these values to comply with your own organization's password policy.
  • Detection steps:
    Check the file /etc/pam.d/system-auth to confirm the password strength verification configuration. Compliance standards: If the password length is >= 8, and it contains at least three types of uppercase letters, lowercase letters, numbers, and special characters, it is compliant, otherwise it is not compliant.
  • Reinforcement solution 1. Configuration file backup
#cp /etc/pam.d/system-auth /etc/pam.d/system-auth.bak
  • 2. Edit the configuration file /etc/pam.d/system-auth and find the content beginning with the following words in the file:
password requisite pam_cracklib.so
Modify it to:
password requisite pam_cracklib.so try_first_pass retry=3 minlen=8 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 #The password length is not less than 8 and contains at least 1 digit, uppercase letters, special characters, and lowercase letters.
2.4 Login failure policy:
  • A failed login policy is a security measure used to prevent malicious users from brute-force password cracking or other attacks by continually trying to log in. The following are the checking steps, configuration methods and reinforcement methods for the login failure policy:
  • Check steps:
    Check the file /etc/pam.d/system-auth and check whether the following content exists: auth required pam_tally2.so deny=5 onerr=fail no_magic_root unlock_time=180 account required pam_tally2.so
  • Compliance standard: If the number of consecutive user authentication failures is set to 5, it is compliant, otherwise it is not compliant.
  • Configuration requirements: For devices that use static password authentication technology, it should be configured to lock the account used by the user when the number of consecutive authentication failures exceeds 6 times (exclusive).
  • Reinforcement method: Refer to configuration operations 1. Perform backup
#cp -p /etc/pam.d/system-auth /etc/pam.d/system-auth_bak
  • 2. Modify the policy settings and edit the file /etc/pam.d/system-auth to add the following content:
auth required pam_tally2.so deny=5 onerr=fail no_magic_root unlock_time=180 #unlock_time unit is seconds
account required pam_tally2.so #(redhat5.1 and above versions support pam_tally2.so, other versions use pam_tally.so)

Please note that before making any modifications, please back up the original configuration files and make sure you understand the meaning and impact of each configuration option. It is recommended to make configuration changes in a test environment and proceed with caution in a production environment

The above is a detailed configuration document of the identity authentication and password security policy based on the Linux CentOS 7 operating system. Please configure accordingly according to actual needs and security requirements.

2.5 Check password lifetime
  • Theoretical basis: The attacker takes advantage of the opportunity of network brute force attack and passes through the window of opportunity of network brute force attack, which is limited by the password life cycle. Therefore, reducing the maximum age of passwords also reduces the attacker’s window of opportunity.
  • Configuration requirements: It is recommended to set the PASS_MAX_DAYS parameter to less than or equal to 90 days.
  • Detection steps: Check the file /etc/login.defs and check whether the following parameter values meet the requirements: PASS_MAX_DAYS
  • Compliance standard: If PASS_MAX_DAYS is not greater than 90, it is compliant, otherwise it is not compliant.
  • Reinforcement solution 1. Perform backup: #cp -p /etc/login.defs /etc/login.defs_bak 2. Modify policy settings, edit the file /etc/login.defs, and add the following content to the file (modify if it exists, Add if not present): PASS_MAX_DAYS 90
  • Risk Explanation If the maximum password age is set too low, users will need to change their passwords frequently. Such a configuration reduces security in the organization because users may write down their passwords in an unsecured location, or lose their passwords. If this policy is set to a value that is too high, it reduces the level of security within your organization because it allows potential attackers more time to discover user passwords or use compromised accounts.
2.6 Check password reuse limit
  • Rationale: Forcing users not to reuse their past five passwords makes it less likely for an attacker to guess the password. Note that these changes only apply to accounts configured on the local system.
  • Configuration requirements: For devices that use static password authentication technology, the device should be configured so that users cannot reuse passwords that have been used in the last 5 times (inclusive).
  • Check steps: Check the file /etc/pam.d/system-auth to see if there is a password reuse limit configured.
  • Compliance standards: If the password reuse limit is no less than 5 times, it is compliant, otherwise it is not compliant.
  • Reinforcement solution 1. Configuration file backup
#cp -p /etc/pam.d/system-auth /etc/pam.d/system-auth.bak
  • 2. Create the file /etc/security/opaswd to store old passwords and set permissions.
#touch /etc/security/opaswd
#chown root:root /etc/security/opaswd
#chmod 600 /etc/security/opaswd
  • 3. Edit the file /etc/pam.d/system-auth, find a line similar to password sufficient pam_unix.so, add remember=5 at the end of the line, separated by spaces. If not, add it.
password sufficient pam_unix.so remember=5
2.7 Check whether chkrootkit is installed for system monitoring
  • Configuration requirements: Install intrusion detection attacks to check whether the Linux system is under attack. In the audit step, execute the following command to check whether the intrusion detection tool is installed on the system #rpm -qa
  • Compliance standards: If the system has the intrusion detection tool chkrootkit installed, it is compliant, otherwise it is not compliant.
  • Reinforcement solution 1. Tool chkrootkit download link http://pkgs.repoforge.org/chkrootkit/chkrootkit-0.49-1.el5.rf.x86_64.rpm 2. Use rpm command to install #rpm -ivh chkrootkit-0.49 -1.el5.rf.i386.rpm 3. Run chkrootkit #chkrootkit
  • Note: chkrootkit output, not infected means not infected.
2.8 Prohibit root user remote login
  • vim /etc/ssh/sshd_config
  • Find the ??PermitRootLogin?? configuration item and modify its value to “no”.
  • Save and close the file.
  • Run the command ??systemctl restart sshd?? to restart the SSH service for the configuration to take effect.