Security O & M: Linux system account and logon Security

Security O & M: Linux system account and logon Security

1. reasonably use the Shell history Command record Function

In Linux, you can use the history command to view all the user's historical operation records, and the shell command operation records are stored in the user directory by default. in the bash_history file, you can use this file to query the execution history of shell commands, which helps O & M personnel perform system audits and troubleshooting. After the server is attacked by hackers, you can also use this command or file to query the historical commands performed by hackers to log on to the server. However, some hackers may delete these commands to destroy the traces after they intrude into the server. bash_history file, which requires reasonable protection or backup. bash_history file. The following describes how to configure the security of the history log file.

The default history command can only view the user's historical operation records, and cannot distinguish the time of each user's operation command. This is inconvenient for troubleshooting, but you can add four lines through the following method) let the history command automatically record the execution time of all shell commands and edit the/etc/bashrc file:

 
 

  
  
HISTFILESIZE=4000   
  
  
HISTSIZE=4000   
  
  
HISTTIMEFORMAT='%F %T' 
  
  
export HISTTIMEFORMAT 
 
 

Here, HISTFILESIZE is defined in. the total number of records stored in the bash_history file. The default value is 1000. Set this parameter to 4000. HISTSIZE defines the total number of records output by the history command. HISTTIMEFORMAT defines the time display format, the format is the same as "+" % F % T "after the date command. As the time variable of history, HISTTIMEFORMAT passes the value to the history command.

After this setting, execute the history command to display the detailed execution time of each historical command, for example:

 
 

  
  
[root@server ~]# history   
  
  
247  2013-10-05 17:16:28 vi /etc/bashrc   
  
  
248  2013-10-05 17:16:28 top 
  
  
249  2013-10-05 17:04:18 vmstat   
  
  
250  2013-10-05 17:04:24 ps -ef   
  
  
251  2013-10-05 17:16:29 ls -al   
  
  
252  2013-10-05 17:16:32 lsattr    
  
  
253  2013-10-05 17:17:16 vi /etc/profile  
  
  
254  2013-10-05 17:19:32 date +"%F %T" 
  
  
255  2013-10-05 17:21:06 lsof  
  
  
256  2013-10-05 17:21:21 history 
 
 

To ensure server security, retaining the execution history of shell commands is a very useful technique. Although shell has historical functions, this function is not designed for auditing purposes, so it is easy to be tampered with or lost by hackers. Next, we will introduce a method to record users, IP addresses, shell commands, and detailed operation time that have logged on to the system in detail, the information is stored in a secure place as a file for system audit and troubleshooting.

Add the following code to the/etc/profile file to implement the above functions.

 
 

  
  
#history   
  
  
USER_IP=`who -u am i 2>/dev/null| awk '{print $NF}'|sed -e 's/[()]//g'`   
  
  
HISTDIR=/usr/share/.history  
  
  
if [ -z $USER_IP ]   
  
  
then  
  
  
USER_IP=`hostname`   
  
  
fi  
  
  
if [ ! -d $HISTDIR ]   
  
  
then  
  
  
mkdir -p $HISTDIR   
  
  
chmod 777 $HISTDIR   
  
  
fi  
  
  
if [ ! -d $HISTDIR/${LOGNAME} ]   
  
  
then  
  
  
mkdir -p $HISTDIR/${LOGNAME}   
  
  
chmod 300 $HISTDIR/${LOGNAME}   
  
  
fi  
  
  
export HISTSIZE=4000   
  
  
DT=`date +%Y%m%d_%H%M%S`   
  
  
export HISTFILE="$HISTDIR/${LOGNAME}/${USER_IP}.history.$DT" 
  
  
export HISTTIMEFORMAT="[%Y.%m.%d %H:%M:%S]" 
  
  
chmod 600 $HISTDIR/${LOGNAME}/*.history* 2>/dev/null 
 
 

This code saves the shell command execution history of each user as a file in/usr/share /. in the history directory, each user has a folder, and each file in the folder is named in the format of IP address and shell command operation time. The following is a history file for user01 to execute shell commands. The basic results are as follows:

 
 

  
  
[root@server user01]#  pwd   
  
  
/usr/share/.history/user01  
  
  
[root@server user01]# ls -al   
  
  
-rw------- 1 user01 wheel  56 Jul  6 17:07 192.168.12.12.history.20130706_164512   
  
  
-rw------- 1 user01 wheel  43 Jul  6 17:42 192.168.12.12.history.20130706_172800   
  
  
-rw------- 1 user01 wheel  22 Jul  7 12:05 192.168.12.19.history.20130707_111123   
  
  
-rw------- 1 user01 wheel  22 Jul  8 13:41 192.168.12.20.history.20130708_120053   
  
  
-rw------- 1 user01 wheel  22 Jul  1 15:28 192.168.12.186.history.20130701_150941   
  
  
-rw------- 1 user01 wheel  22 Jul  2 19:47 192.168.12.163.history.20130702_193645   
  
  
-rw------- 1 user01 wheel  22 Jul  3 12:38 192.168.12.19.history.20130703_120948   
  
  
-rw------- 1 user01 wheel  22 Jul  3 19:14 192.168.12.134.history.20130703_183150 
 
 

The folder directory for storing historical commands should be hidden as much as possible to avoid deletion after being discovered by hackers.

Ii. reasonably use the su and sudo commands

The su command is a tool for switching users. It is often used to switch common users to Super Users. Of course, it can also switch from Super Users to normal users. To ensure the security of the server, almost all servers prohibit superusers from directly logging on to the system. Instead, they log on to the system through common users and then switch to the superuser using the su command, execute jobs that require super permissions. The su command can bring some convenience to system management, but there are also some insecure factors. For example, the system has 10 common users, and each user needs to perform operations with super permissions, the Super User Password must be handed over to these 10 normal users. If these 10 users have super permissions, they can do anything through Super permissions, to a certain extent, security of the system will be affected. Therefore, the su command is not the best choice in system management that many people need to participate in. The super user password should be in the hands of a few people, and The sudo command will be used in this case.

The sudo command allows the system administrator to assign reasonable "rights" to common users and does not require common users to know the superuser password, this allows them to execute tasks that can only be completed by super users or other authorized users, such as system service restart and system configuration file editing, this method not only reduces the number of superuser logins and management time, but also improves system security. Therefore, the sudo command is safer than the unrestricted su command, so sudo is also known as the restricted su. In addition, sudo requires prior authorization and authentication, therefore, it is also called the su for authorization authentication.

The sudo Command Execution Process is to switch the current user to a Super User, or to a specified user, and then execute the command as a super user or the user with the specified switch. After the command is executed, return directly to the current user, and The sudo configuration file/etc/sudoers must be used for authorization.

For example, normal users of the/etc/shadow file cannot access the file:

 
 

  
  
[user01@unknown ~]$ more /etc/shadow  
  
  
/etc/shadow: Permission denied 
 
 

If you want user01 to access this file, you can add the following content in/etc/sudoers:

 
 

  
  
User01 ALL =/bin/more/etc/shadow
  
  
In this way, the user01 user can access the/etc/shadow file in the following way:
  
  
[User01 @ unknown ~] $ Sudo more/etc/shadow
  
  
[Sudo] password for user01:
 
 

After executing this command, you need to enter the user01 user password, and then you can access the file content. Here, sudo uses a timestamp file to complete a system similar to "ticket checking, after you enter the password, you will get a "admission ticket" with a default storage period of 5 minutes. The default value can be changed during compilation ). After the timeout, you must re-enter the password to view the file content.

If you need to enter a password every time, some programs that automatically call the super permission will encounter problems. In this case, you can use the following settings, allows normal users to execute programs with super permissions without entering a password. For example, to enable normal centreon users to have the permission to restart the/etc/init. d/nagios script, add the following settings in/etc/sudoers:

 
 

  
  
CENTREON   ALL = NOPASSWD: /etc/init.d/nagios restart 
 
 

In this way, the normal user centreon can execute the nagios restart script without entering the password. If you want to allow a common user user02 to have all the permissions of the superuser without entering the superuser password, you only need to add the following content in/etc/sudoers:

 
 

  
  
user02 ALL=(ALL) NOPASSWD: ALL 
 
 

In this way, after logging on to the system, the user02 user can run the following command to switch to the Super User:

 
 

  
  
[user02@unknown ~]$ sudo su -   
  
  
[root@unknown ~]# pwd   
  
  
/root 
 
 

Sudo is designed to grant users as few permissions as possible but still allow them to do their work. This design combines security and ease of use. Therefore, we strongly recommend that you use sudo to manage the security of system accounts and only allow common users to log on to the system. If these users require special permissions, you can configure/etc/sudoers, this is also the basic method for account security management under multi-user systems.

3. delete system logon welcome information

Although some welcome information or version information of the system can bring some convenience to system administrators, this information may sometimes be used by hackers to attack servers. To ensure system security, you can modify or delete some system files. Four files need to be modified or deleted, they are/etc/issue,/etc/issue.net,/etc/redhat-release, and/etc/motd.

The/etc/issue and/etc/issue.net files both record the name and version number of the operating system. When a user logs on to the system through a local terminal or a local virtual console, the/etc/issue file content is displayed. When you log on to the system remotely through ssh or telnet, the/etc/issue.net file content is displayed after logon. By default, the content of the/etc/issue.net file is not displayed after ssh logon. To display this information, you can modify the/etc/ssh/sshd_config file, add the following content to this file:

 
 

  
  
Banner /etc/issue.net 
 
 

In fact, these logon prompts clearly leak system information. For security reasons, we recommend that you delete or modify the content in this file.

The/etc/redhat-release file also records the name and version number of the operating system. To ensure security, you can delete the content in this file.

The/etc/motd file is the system announcement information. After a user logs on, the content of the/etc/motd file is displayed on the user's terminal. Through this file system administrator can publish some software or hardware upgrades, system maintenance and other announcement information, but the biggest role of this file is to publish some warning information, when a hacker logs on to the system, the warning information is found, which can cause some deterrent effect. I have read a foreign report that hackers intrude into a server, but the server provides welcome information, so the court does not make any ruling.

Blog: http://ixdba.blog.51cto.com/2895551/1552907