System Security ------- Account Security Management

System account management

Account cleanup

  • Accounts are divided into login users and non-login users:
    login users: super user root, ordinary users created by themselves, and other users used by others.
    Non-login users: A large number of other account packages generated with the system or program installation process (such as bin, daemon, adm, ip, mail, nobady, apache, mycql, dbus, ftp, gdm, haldaemon, etc.)

  • In order to ensure system security, the shells of these non-login users are usually /sbin/nologin, which means that terminal logins are forbidden to ensure that others cannot change them at will.

[root@localhost~]#grep “/sbin/nologin” /etc/passwd ######You can view non-login users who are not allowed to log in

And quite a few of these non-login users are rarely used or not used at all. These accounts can be regarded as redundant accounts. They are not used for anything but take up space for booting speed, etc., so we can delete them directly.

  • For long-term unused user accounts in the Linux server, you are not sure whether you can delete them, you can lock them temporarily and delete them later.

Example:
[root@localhost~]#usermod -L xiaojiejie or passwd -l xiaojiejie ########Lock account
[root@localhost~]#passwd -S xiaojiejie #########View account Is it locked?

[root@localhost~]#usermod -U xiaojiejie or passwd -u xiaojiejie ############Unlock account
[root@localhost~]#passwd -S xiaojiejie ######### #Check whether the account is locked

  • The safest thing is to lock the configuration file of the account. As long as it is locked, it cannot be deleted if it is not unlocked. Accounts cannot be added, passwords cannot be changed, login shells, home directories and other attribute information.

[root@localhost~]#chattr +i /etc/passwd /etc/shadow #######Lock the file
[root@localhost~]#lsattr /etc/passwd /etc/shadow ####### ####Check the status of the lock
----i-------- /etc/passwd
----i-------- /etc/shadow
[root@localhost~]#chattr -i /etc/passwd /etc/shadow #########Unlock file
[root@localhost~]#lsattr /etc/passwd /etc/shadow ###########View lock Status of
------------- /etc/passwd
------------- /etc/shadow

Account security settings

In an insecure network environment, in order to reduce the risk of password guessing or brute force cracking, users should develop the habit of changing passwords regularly to avoid using the same password for a long time. The administrator can limit the maximum number of valid days for a user's password on the server side. For users whose passwords have expired, they will be asked to reset their passwords when logging in, otherwise they will refuse to log in.
The password is valid for 30 days:
[root@localhost~]#vi /etc/login.defs ###########Applies to newly created users
PASS_MAX_DAYS 30 ########Add this command
[root@localhost~]#chage -M 30 lisi ###########Applicable to existing lisi users

All users are uniformly required to change the new password:
[root@localhost~]#chage -d 0 xiaojiejie ##########Requires that the lady sister user needs to change the password next time he logs in

Delete history command

To prevent your computer from being invaded, check your history commands and you will know which commands you have lost.
There are two ways to clear history commands:
1. history -C ########## can only clear the current time the history command, restart the machine will appear again
2, ** vi /.bash_profile**#######vi editor /.bash_profile
Export HISTSIZE = 0 ###### add this command to restart after Delete this command, under refresh

User switching and privilege escalation

Most Linux servers do not recommend that users log in directly as the root user. On the one hand, it can greatly reduce the damage caused by incorrect operations. On the other hand, it also reduces the risk of privileged passwords being leaked in an insecure network environment. For these reasons, it is necessary to provide an identity switching or privilege escalation mechanism for ordinary users to perform management tasks when necessary.

su command-switch account

Example:
[root@localhost~]#su-root ##############Switch to root account
password:

The option "-" means to enter the login shell environment of the target user after switching users. If this option is missing, only the identity is switched, and the user environment is not switched. For switching root users, the target root can be omitted.

  • By default, any user is allowed to use the su command, which gives the opportunity to repeatedly try the login password of other users (such as root), which brings security risks. In order to strengthen the control of the use of the su command, the pam_wheel authentication module can be used to allow very few users to switch using the su command.
    Example:
    Add the user kcce authorized to use the su command to the wheel group, modify the /etc/pam.d/su authentication configuration to enable pam_wheel authentication
    [root@localhost~]#gpasswd -a kcce wheel ######Add authorization User kcce
    (display:) Adding user kcce to group wheel
    [root@localhost~]#grep wheel /etc/group ###########Confirm wheel group members
    (display:) wheel: x: 10: kcce
    [root@localhost~] #vi /etc/pam.d/su ###########Edit the configuration file /etc/pam.d/su
    (display:) #%PAM-1.0
    auth sufficient pam_rootok.so

    auth required pam_wheel so use_uid #############Remove the # sign at the beginning of this line

After pam_wheel authentication is enabled, other users who have not been added to the wheel group will not be able to use the su command, and "Permission denied" will be displayed when trying to switch.

sudo command-elevate execution authority

When you are a normal user when executing commands, you will sometimes be prompted that you do not have permission to execute, which will make you very uncomfortable, so at this time you have to switch to the super user root account, so you must know the password of the root account. Every more person on the Linux server in the environment knows the privileged password, the security risk increases by one point. In this case, the administrator neither wants to give you the password but also allows you to have privileges to execute commands. You can use sudo Ordered. (Of course this has to be the administrator's business, he needs to set it up)


  • The configuration file for adding the authorization sudo mechanism in the configuration file /etc/sudoers is /etc/sudoers. The default permission of the file is 440, which needs to be edited with a special visudo tool.
    You can also use vi /etc/sudoers to edit the file, but you must perform the "wq!" mandatory operation when saving, otherwise the system will prompt for a read-only file and refuse to save the
    format: user MACHINE=COMMANDS
    #: user (user): authorized user name , Or in the form of "% group name" (authorize all users of a group)
    #: host (MACHINE): host name using this configuration file, this part is mainly to facilitate sharing the same sudoers file among multiple hosts, generally Just set it to localhost or the actual host name.
    #: Command (COMMANDS): Authorized commands that allow authorized users to execute through sudo. You need to fill in the full path of the command program, and multiple commands are separated by commas ",".
    1. In a typical sudo configuration record, each line corresponds to a user or group's sudo authorization configuration
    example:
    to authorize user Jerry to execute the ifconfig command to modify the IP address, and users in the wheel group can execute the file without verifying the password

[root@localhost~]# visudo
(…omit a lot of content)
Jerry localhost=/sbin/ifconfig
%wheel (a few spaces are empty) ALL=NOPASSWD:ALL

——————————————— ———————
2. When there are more users with the same authorization or more authorized commands, you can use the centralized defined alias to set.
User (User_Alias), host (Host_Alias), command (Cmnd_Alias)
example:
add authorization records through aliases, allowing users Jerry, tom, and kcce to execute rpm and yum commands on hosts smtp and pop

[root@localhost~]#visudo
(...omit part of the content)
User_Alias ​​(space) OPERATORS=jerry,tom,kcce
Host_Alias ​​(space) MAILSVRS=smtp,pop
Cmnd_Alias ​​(space) PKGTOOLS=/bin/rpm,/usr/bin/ yum
OPERATORS (space) MAILSVRS=PKGTOOLS
———————————————————————
3. The command part of sudo configuration record allows the use of wildcard "*" and negation symbol " !", especially useful when you need to authorize all commands in a directory or cancel individual commands.
Example:
Authorized user kkg can execute all other command programs in the /sbin/ directory except ifconfig and route

[root@localhost~]#visudo
(...omit part of the content)
kkg localhost=/sbin/*,!/sbin/ifconfig,!/sbin/route
————————————————— ——————

4. If the administrator wants to view the sudo log records, he should add "Defaults logfile" to the /etc/sudoers file. Setting
example:
[root@localhost~]#visudo
(...part of the content is omitted)
Defaults logfile = "/var/log/sudo

  • Execute privileged commands through sudo
    1. When ordinary users enter commands, they will get a prompt that the permissions are insufficient

[kcce@localhost~]$ /sbin/ifconfig egh0 192.168.1.11/24 #######If sudo is not used
SIOCSIFADDR: not enough permissions
SIOCSIFNETMASK: not enough permissions
...
[kcce@localhost~]$ sudo /sbin/ifconfig egh0 192.168.1.11/24 #########When using sudo
...
passwd for user:

[kcce@localhost~]$/sbin/ifconfig egh0 ##########View execution results

When you execute a command through sudo for the first time, you must verify with the user's own password (not the password of the root user or other users). Afterwards, when you execute the command through sudo again, as long as the interval with the previous sudo operation does not exceed 5 minutes, Do not repeat the verification.

2. Authorized users check their sudo configuration, and users who are not configured will get the prompt "may not run sudo".
Example:
[kcce@localhost~]$visudo

User kcce can run the following command on the host:
kcce localhost=/sbin/ifconfig

3. If the sudo log has been enabled, you can see the user's sudo operation record
example from the /var/log/sudo file :
[kcce@localhost~]$tail /var/log/sudo

May 13 09:49:47 : kcce: PTS = the TTY / 0; the PWD = / Home / kcce; the USER = the root;
the COMMAND = / sbin / the ifconfig eth0: 0 192.168.1.11/24
...

Guess you like

Origin blog.csdn.net/XCsuperman/article/details/107518596