General processing after a Linux server is compromised

Security is always relative, and a safe server can be compromised. As a safe operation and maintenance personnel, to grasp the principle is: as far as possible to do a good job of system security, repair all known dangerous behavior, while the system is under attack can quickly and effectively deal with attack behavior, minimize the impact of the attack on the system.

First, the general idea of dealing with the attack of server

System attack is not terrible, terrible is the face of attack helpless, the following detailed introduction under the server after the attack of the general processing ideas.

1. Disconnecting the network

All attacks come from the network, so after knowing that the system is being attacked by hackers, the first thing to do is to disconnect the server network, so in addition to cutting off the source of the attack, but also to protect the server on the network of other hosts.

2. Find the source of the attack

You can view suspicious information by analyzing the system log or log-in log files, as well as seeing which ports are open on the system, which processes are running, and what are the suspicious programs through these processes. This process must be traced and analyzed based on experience and comprehensive judgment. The following sections describe the process in detail.

3. Analysis of the causes and ways of intrusion

Since the system has been compromised, then the reasons are manifold, may be a system vulnerability, it may be a program vulnerability, it is important to find out what caused the cause, and also to find out the way to attack, to locate the source of the attack, because only know the cause of the attack and the way to remove the attack source and the vulnerability of the repair.

4. Backing up user data

After the server is attacked, you need to back up the user data on the server immediately, and also see if the source of the attack is hidden in the data. If the source of the attack is in the user data, be sure to delete it completely and then back up the user data to a safe place.

5. Reinstall the System

Never think that you can completely clear the source of the attack, because no one can better understand the attack program than hackers, after the server is attacked, the safest and easiest way is to reinstall the system, because most of the attacks will be attached to the system files or kernel, so reinstall the system to completely clear the source of the attack.

6. Hotfix or System vulnerability

After discovering a system vulnerability or application vulnerability, the first thing to do is to fix the system vulnerability or change the program bug, because only the bug of the program can be repaired to formally run on the server.

7. Recovering data and connecting to the network

Re-copy the backed-up data to the newly installed server, then turn on the service, and finally open the server to network connection and provide services externally.

Second, check and lock suspicious users

When the server is found to be attacked, the first to cut off the network connection, but in some cases, such as the inability to immediately cut off the network connection, you must log on to the system to see if there are suspicious users, if a suspicious user logged in the system, you need to lock the user immediately, and then interrupt this user's remote connection.

1. Log in to the system to view suspicious users

Log in with the root user and then execute the "w" command to list all users who have logged on to the system, as shown in.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/4D/E7/wKiom1RcQuSyzGCSAACCcrPjs1g335.jpg "title=" QQ picture 20141107115147.jpg "alt=" Wkiom1rcqusyzgcsaacccrpjs1g335.jpg "/>

This output allows you to check for suspicious or unfamiliar user logins, and also to determine if they are illegal, based on the user name and the source address of the user's login and the process they are running.

2. Lock suspicious users

Once the suspicious user is found, it is necessary to lock it immediately, such as the "W" command above to find that the nobody user should be a suspicious user (because nobody by default is not logged on), so first lock the user, do the following:

[Email protected] ~]# Passwd-l Nobody

After locking, it is possible that the user is still logged in, so also to kick the user offline, according to the output of the "W" command above, you can get the PID value of this user login, the operation is as follows:

[Email protected] ~]# Ps-ef|grep @pts/3

531 6051 6049 0 19:23? 00:00:00 sshd: [Email PROTECTED]/3

[Email protected] ~]# kill-9 6051

In this way, the suspect user nobody kicked off the line. If the user tries to log on again, it is unable to log on.

3. View user logon events with last command

Last command records all users log on the system, can be used to find non-authorized users of logon events, and the last command output from the/var/log/wtmp file, a slightly experienced intruder will delete/var/log/wtmp to clear their whereabouts, But it's still going to reveal clues in this file.

Third, view the system log

Viewing the system log is the best way to find the source of the attack, the system log can be checked for/var/log/messages,/var/log/secure, and so on, these two log files can record the running state of the software and the remote user's login status, you can also view each user directory. Bash_ The history file, especially the. bash_history file in the/root directory, which records all the historical commands performed by the user.

Iv. checking and shutting down the system suspicious process

There are many commands to check for suspicious processes, such as PS, Top, and so on, but sometimes only knowing the name of the process does not know the path, which can be viewed by the following command:

The Pidof command is the first way to find the running process PID, for example to find the PID of the sshd process, and execute the following command:

[Email protected] ~]# pidof sshd30545 1025

Then go to the memory directory to see the corresponding PID directory exe file information:

[[email protected] ~]# Ls-al/proc/30545/exe lrwxrwxrwx 1 root root 0 November 7 10:12/proc/30545/exe-/usr/sbin/sshd

The complete execution path corresponding to the process is found. If you also have a handle to the view file, you can view the following directory:

[Email protected] ~]# LS-AL/PROC/30545/FD

[[email protected] ~]# fuser -n tcp  111111/tcp:               944[[ email protected] ~]# fuser -n tcp 2525/tcp:                1202[[email protected] ~]# ps -ef| grep 1202root      1202     1  0  nov01 ?        00:00:07 sendmail: accepting  connectionsroot      8767 30551  0 12:03 pts/0     00:00:00 grep 1202 

In some cases, the attacker's program is hidden deep, such as the rootkits backdoor, in which case the PS, top, netstat and other commands may have been replaced, if the system's own command to check the suspicious process becomes not credible, at this time, It is necessary to use third-party tools to check system suspicious programs, such as the previously described Chkrootkit, Rkhunter and other tools, through these tools can easily find the system is replaced or tampered with the program.

Five, check the integrity of the file system

Checking the file properties for changes is the simplest and most straightforward way to verify file system integrity, such as checking that the size of the/bin/ls file on the compromised server is the same size as the file on the normal system to verify that the file is replaced, but this method is low-level. This can be done with Linux under the RPM tool to complete the verification, the operation is as follows:

[[email protected] ~]# rpm -va. 5....t.  c /usr/lib64/security/classpath.security ..... T.    /usr/share/pear/.depdb ..... T.    /usr/share/pear/.depdblocks.5 .... T.    /usr/share/pear/.filemap ..... T.    /usr/share/pear/.lock ..... T.  c /etc/mail/local-host-names .... L....  c /etc/pam.d/fingerprint-auth .... L....  c /etc/pam.d/password-auth .... L....  c /etc/pam.d/smartcard-auth .... L....  c /etc/pam.d/system-auths.5 .... T.  c /etc/php.inis.5 .... T.  c /etc/yum.repos.d/centos-base.repo ..... T.  c /etc/inittabs.5 .... T.  c /etc/rc.d/rc.locals.5 .... T.  c /etc/snmp/snmpd.confs.5 .... T.  c /etc/maven/maven2-depmap.xmls.5 .... T.  c /etc/httpd/conf/httpd.conf 

The meaning of each tag in the output is described below:

S indicates that the file length has changed

M indicates file access or file type has changed

5 indicates that the MD5 checksum has changed

D indicates that the properties of the device node have changed

L indicates that the file's symbolic link has changed

U indicates that the owner of the file/subdirectory/device node has changed

G indicates that the file/subdirectory/Device node group has changed

T indicates that the last modification time of the file has changed

If an "M" tag appears in the output, the corresponding file may have been tampered with or replaced, and the file can be purged by uninstalling the RPM package to reinstall the attack.

However, this command has a limitation, that is, can only check the RPM package installation of all files, for the non-RPM package installation of files are powerless. At the same time, if the RPM tool is also replaced, it is not possible to use this method, at this time you can copy a RPM tool from the normal system to detect.

File system inspection can also be done through the Chkrootkit, Rkhunter tools, about the use of Chkrootkit, Rkhunter tools, Next will expand the introduction.

This article is from the "-it commune" blog, please be sure to keep this source http://guangpu.blog.51cto.com/3002132/1573977

General processing after a Linux server is compromised