A reasonable use of the shell History command logging function
Under Linux, the History command allows you to view all of the user's historical operations records, while the shell command action record is saved by default in the. bash_history file in the user directory, which allows you to query the execution history of the shell command. Help operations personnel to conduct system audits and troubleshooting, while the server has been hacked, you can also use this command or file to query the hacker login server to perform the historical command operation, but sometimes hackers in order to destroy the server after the destruction of traces, may be deleted. bash_history file, This requires a reasonable protection or backup. bash_history file. The following describes the security configuration method for the following history log files.
The default history command can only view the user historical action record, and does not distinguish the time of each user action command, which is inconvenient to troubleshoot the problem, but you can use the following method (add four lines of content) to let the history command automatically record the execution time of all shell commands, edit/etc/ BASHRC file:
histfilesize=4000histsize=4000histtimeformat= '%F%T ' export Histtimeformat
Where histfilesize defines the total number of records to save the command in the. bash_history file, the default value is 1000, which is set to 4000;histsize defines the total number of records for the history command output Histtimeformat defines the time display format, where the format is consistent with the "+"%F%T "" After the date command, and Histtimeformat is passed to the history command as a time variable for history.
With this setting, the history command is executed, showing the detailed execution time of each historical command, for example:
[Email protected] ~]# history247 2013-10-05 17:16:28 VI/ETC/BASHRC 248 2013-10-05 17:16:28 top249 2013-10-05 17:04:18 vmstat250 2013-10-05 17:04:24 ps-ef251 2013-10-05 17:16:29 ls-al252 2013-10-05 17:16:32 lsattr 253 2013-10-05 17:17 : vi/etc/profile254 2013-10-05 17:19:32 date + "%F%T" 255 2013-10-05 17:21:06 lsof256 2013-10-05 17:21:21 History
Preserving the execution history of shell commands is a useful technique to ensure server security. Although the shell has historical functions, this feature is not designed for auditing purposes and is therefore easily tampered with or lost by hackers. Here is another way to implement detailed logging of logged-in System users, IP addresses, shell commands, and detailed operation time, and this information in the form of files in a safe place, for system audit and troubleshooting.
Add the following code to the/etc/profile file to achieve the above functionality.
#historyUSER_IP = ' Who-u am I 2>/dev/null| awk ' {print $NF} ' |sed-e ' s/[()]//g ' histdir=/usr/share/.historyif [-Z $USER _ip]thenuser_ip= ' hostname ' FIIF [!-D $HISTD IR]thenmkdir-p $HISTDIRchmod 777 $HISTDIRfiif [!-D $HISTDIR/${logname}]thenmkdir-p $HISTDIR/${logname}chmod $HIS Tdir/${logname}fiexport histsize=4000dt= ' date +%y%m%d_%h%m%s ' export histfile= ' $HISTDIR/${logname}/${user_ip}. History. $DT "Export histtimeformat=" [%y.%m.%d%h:%m:%s] "chmod $HISTDIR/${logname}/*.history* 2>/dev/null
This code saves each user's shell command execution history as a file in the/usr/share/.history directory, each user a folder, and each file under the folder is named with the IP address plus the shell command operation time format. The following is a history file of the User01 user executing the shell command, with the following basic effects:
[[email protected] user01]# pwd/usr/share/.history/user01[[email protected] 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
Keep the folder directory of History commands as discreet as possible to avoid being deleted by hackers.
Second, reasonable use of Su, sudo command
The SU command is a tool for switching users, and is often used to switch ordinary users to superuser and, of course, from a superuser to a normal user. In order to ensure the security of the server, almost all servers prohibit the superuser to log into the system directly, but through the normal user login system, and then through the SU command to switch to the superuser, to perform some work that requires super privilege. Through the SU command can bring some convenience to the system management, but there are also unsafe factors, such as the system has 10 ordinary users, each user needs to perform some super-privileged operation, you must give the super user password to the 10 ordinary users, if the 10 users have super permissions, Can do anything through super-privilege, then to some extent, the security of the system caused the association. Therefore, the SU command in many people need to participate in the system management, is not the best choice, super-user password should be in the hands of a few, when the sudo command comes in handy.
The sudo command allows the system administrator to assign a reasonable "right" to a normal user, and does not require the user to know the Superuser's password, allowing them to perform tasks that only superuser or other privileged users can accomplish, such as system service restarts, editing system configuration files, etc. This approach not only reduces the number of super-user logins and administration time, but also improves system security. As a result, the sudo command is still relatively secure relative to the unrestricted permission Su, so sudo is also known as the restricted Su, and sudo is also known as an authenticated SU because it requires prior authorization authentication.
The process for sudo to execute a command is to switch the current user to a superuser, or to switch to the specified user, and then execute the command as a superuser or the user it specifies to switch to, and then return directly to the current user when the execution is complete, and all of this is done via sudo's configuration file/etc/ Sudoers to authorize.
For example,/etc/shadow files are inaccessible to ordinary users:
[Email protected] ~]$ More/etc/shadow/etc/shadow:permission denied
If you want to allow normal user User01 to access this file, you can add the following in/etc/sudoers:
User01 all =/bin/more/etc/shadow this way, the/etc/shadow file can be accessed by User01 users as follows: [[email protected] ~]$ sudo more/etc/shadow[sudo ] Password for User01:
After executing this command, you need to enter the password of the User01 user, and then you can access the contents of the file. Here sudo uses a timestamp file to complete a system similar to "Ticket-check", when the user enters a password and obtains a "ticket" with a default survival period of 5 minutes (the default value can be changed at compile time). After the timeout, the user must reenter the password to view the contents of the file.
If you need to enter a password each time, some of the programs that automatically invoke the super-permissions will be problematic, at this point, you can use the following settings, so that ordinary users do not have to enter a password to execute a program with super privileges. For example, to let a normal user Centreon have/etc/init.d/nagios script Restart permissions, you can add the following settings in/etc/sudoers:
CENTREON all = nopasswd:/etc/init.d/nagios restart
This allows the normal user Centreon to execute the nagios restart script without entering a password. If you want a normal user to user02 all the privileges of a superuser, without entering the superuser's password, simply add the following to the/etc/sudoers:
User02 all= (All) Nopasswd:all
After the User02 user logs on to the system, you can switch to the superuser by executing the following command:
[[email protected] ~]$ sudo su-[[email protected] ~]# pwd/root
The purpose of sudo design is to give users as few permissions as possible but still allow them to do their work, this design takes into account security and ease of use, so it is highly recommended to manage the security of the system account through sudo, only allow ordinary users to log on the system, if these users need special permissions, by configuring/etc /sudoers to complete, this is also a multi-user system account security management basic way.
Iii. deletion of system login Welcome information
Some of the system's welcome information or version information, although it can bring some convenience to the System Manager, but this information can sometimes be exploited by hackers, as an accomplice to attack the server, in order to ensure the security of the system, you can modify or delete some system files, there are 4 files that need to be modified or deleted, respectively/etc/ Issue,/etc/issue.net,/etc/redhat-release and/ETC/MOTD.
Both the/etc/issue and/etc/issue.net files record the name and version number of the operating system, and when the user logs on to the system via a local terminal or a local virtual console, the contents of the/etc/issue file are displayed when the user Telnet to the system via SSH or Telnet. , the contents of the/etc/issue.net file are displayed after login. By default, the content of the/etc/issue.net file is not displayed after SSH login, to display this information can modify the/etc/ssh/sshd_config file, add the following content in this file:
Banner/etc/issue.net
In fact, these login tips are obviously leaking system information, for security purposes, it is recommended to delete or modify the contents of this file.
The/etc/redhat-release file also records the name and version number of the operating system, and for security reasons, you can delete the contents of this file.
The/ETC/MOTD file is a system announcement information. Each time the user logs in, the contents of the/ETC/MOTD file are displayed in the user's terminal. Through this file system administrator can release some software or hardware upgrades, system maintenance and other notification information, but this file is the most useful, can be issued some warning message, when the hacker logged into the system, will find these warning messages, and then have some deterrent effect. Read a foreign report, the hacker hacked a server, and this server gave a welcome login information, so the court does not make any decision.
This article is from the "Technical Achievement Dream" blog, please be sure to keep this source http://ixdba.blog.51cto.com/2895551/1552907
Secure Operation Koriyuki: Linux SYSTEM account and login security