OS Hardening Overview
This chapter describes the purpose and solution of openEuler system hardening.
Notice
Security hardening is crucial for system security. Therefore, only the root user is allowed to change and apply security hardening policies.
Security Hardening Purpose
The OS, as the core of the information system, manages hardware and software resources and is the basis of information system security. Applications must depend on the OS to ensure the integrity, confidentiality, availability, and controllability of information. Without the OS security protection, protective methods against hackers and virus attacks at other layers cannot meet the security requirements.
Therefore, security hardening is essential for an OS. Security hardening helps build a dynamic and complete security system, enhance product security, and improve product competitiveness.
Security Hardening Solution
This section describes the openEuler security hardening solution, including the hardening methods and items.
Security Hardening Method
You can manually modify security hardening configurations, run commands to harden the system, or use a security hardening tool to modify security hardening configurations in batches. security-tool runs as openEuler-security.service. When the system is started for the first time, the system automatically runs the service to execute the default hardening policy, and sets the service not to start as the system starts.
You can modify the /etc/openEuler_security/usr-security.conf file and use the security hardening tool to implement customized security hardening.
Security Hardening Impacts
Security hardening on file permissions and account passwords may affect user habits and system usability. For details about common hardening items that affect system usability, see Table 1.
Table 1 Security hardening impacts
Item | Suggestion | Impact | Configured By Default |
---|
Timeout setting on the text-based user interface (TUI) | When the TUI is idle for a long period of time, it automatically exits. NOTE:When a user logs in to the system using SSH, the timeout period is determined by the smaller value of the TMOUT field in the /etc/profile file and the ClientAliveInterval field in the /etc/ssh/sshd_config file. You are advised to set the timeout period to 300 seconds. | If you do not perform any operation on the TUI for a long time, TUI automatically exits. | No |
Password complexity | The password is a string containing at least eight characters chosen from three or four of the following types: uppercase letters, lowercase letters, digits, and special characters. | All passwords must comply with the complexity requirements. | No |
Password retry limits | If a user fails to enter the correct password for three consecutive times when logging in to the OS, the user account will be locked for 60 seconds. | After the account is locked, the user can attempt to log in to the system only after 60 seconds. | Yes |
Default umask value | The default umask value of all users is set to 077 so that the default permission on files created by users is 600 and the default permission on directories is 700. | The default permission on created files is 600 and the default permission on created directories is 700. You can modify the permissions after a file or directory is created. | No |
Password validity period | The password validity period can be modified in the /etc/login.defs file and is set to 90 days by default. It can be modified in any time. An expiration notification will be displayed seven days before a password is to expire. | When a user attempts to log in after the password expires, the user will be informed of the password expiry and is required to change the password. If the user does not change the password, the user cannot log in to the system. | No |
su permission control | The su command is used to switch user accounts. To improve system security, only the user root and users in the wheel group can use the su command. | Common users can successfully run the su command only after joining in the wheel group. | Yes |
Prohibiting user root from logging in using SSH | Set the value of the PermitRootLogin field in the /etc/ssh/sshd_config file to no. In this way, user root cannot directly log in to the system using SSH. | The user needs to log in to the system using a common account in SSH mode, add the common user to the wheel group, and then switch to the root user. | No |
Strong SSH encryption algorithm | The MACs and Ciphers configurations of SSH services support the CTR and SHA2 algorithms and do not support the CBC, MD5, and SHA1 algorithms. | Some early Xshell and PuTTY versions on Windows do not support aes128-ctr, aes192-ctr, aes256-ctr, hmac-sha2-256, and hmac-sha2-512 algorithms. Ensure that the latest PuTTY (0.63 or later) and Xshell (5.0 or later) are used. | Yes |