IT industry development up to now, security has become crucial, from the recent "prism" incident, reflects a lot of security issues, information security has become urgent, and as the operation and maintenance personnel, we must understand Some security guidelines for operation and maintenance, at the same time, to protect their own responsible business, we must first stand in the perspective of an attacker's thinking, repair any potential threats and vulnerabilities.
The following case was introduced to by a server when a rootkit is post-invasion ideas and treatment process, rootkit attacks are the most common Linux system attacks and attack.
1, attack phenomenon
This is a customer portal server, hosted in the telecommunications room, the customer notified Telecom: Due to continuing this server sends out packets, resulting in 100M of bandwidth is exhausted, then cut off telecommunications network this server. This server is Centos5.5 version, opening up the ports 80,22. From customers understand site traffic is not large, so the bandwidth will not be too high, and depletion 100M bandwidth is absolutely impossible, it is very likely that the server suffered a traffic attack, so do the login server detailed testing.
2, preliminary analysis
In cooperation with telecommunications staff through the switch to the network server traffic detection and found that the host does exist outside traffic scanning port 80, then log into the system to check for open ports on your system by the netstat -an command, it can be strange and found nothing related to the 80-port network connection.
Then use ps -ef, top commands did not find any suspicious process. So I doubt whether the system is implanted rootkit. To prove whether the system is implanted in the rootkit, we will be under the web server ps, top commands with the same version of backup credibility before the operating system command md5sum check done and found that these two commands under the web server really is modified, thus concluded that this server has been compromised and the level of installed rootkit backdoor.
3, broken network analysis system
Since the server stop contracting out, therefore, the first thing to do is disconnect the network this server, and then analyze the system log for the attack source. But the system command has been replaced, and if it continues to perform operations on the system will be trusted, this situation can be avoided here by two methods, the first method is hard to take the server down to mount this the analysis of safety on another host.
Another way is to copy from the next version with a trusted operating system all commands to a server path to this invasion, then specify the full path to this command at the time of execution of the command, this uses the second method.
We first see the login log system to see if there is suspicious login, execute the following command:
More / var / log / Secure | grep Accepted
by looking at the command output, there is a log aroused our suspicion:
Oct 3 03: 10:25 webserver sshd [20701]: Accepted password for mail from 62.17.163.186 port 53349 ssh2
this log shows the number at 3:10 on October 3, there is a mail account from the IP 62.17.163.186 successfully logged into the system , mail is the system's built-in account, by default, is unable to perform the login operation, while the 62.17.163.186 IP, after verification, an address is from Ireland.
From the point of view of time mail account login, web server suffered early this time of the attack. Then look at the system password file / etc / shadow, discovered suspicious information:
mail:
kCEd3yD6 $ W1evaY5BMPQIqfTwTVJiX1: 15400: 0: 99999: 7 :::
Obviously, mail account password has been set, and can be modified as remote login, the reason for using the mail account, guess probably because the intruder want to leave a hidden account, in order to facilitate the registration system in the future. Then continue to view other system logs such as / var / log / messages, /file are empty, we can see, the intruder has cleared the system log files, as to why there is no empty / var / log / secure file, you I do not know.
4, find the source of the attack
So far, what we know is that there is a mail account had logged in the system, but why continue to cause this server sends out packets it? Must find the corresponding source of the attack, view the process by replacing the ps command on this server currently running system, but also found a new suspect:
? The nobody 22765 1 6 Sep29 4-00: 11: 58 .t
this program .t What is it, proceed to the top command, the following results:
PID the USER PR the NI VIRT RES SHR S% the CPU% MEM the TIME + the cOMMAND
22765 the nobody 15 0 1740m 1362m 1228 S 98.3 91.5 2892: 19 .T
seen from the output, this t program is already running about 4 days, to run this program is that nobody user, and this t program consumes a lot of memory and cpu, which is why before customers reflect the site server unusually slow, from this output, we get the process t program PID to 22765, according to the path followed by the execution of the program where to find the next PID: enter the memory directory, the directory information see the corresponding PID exe file under:
[root @ webserver ~] # / mnt / bin / LS -al / proc / 22765 / EXE
lrwxrwxrwx 1 root root 0 Sep 29 22:09 / proc / 22765 / EXE -> / var / tmp / ... / APA / t
thus find the complete program execution process corresponding to the path, the path is very subtle, because the / var / tmp directory User readability under any circumstances recognize, while the intruder is to use this loophole created in the / var / tmp directory with a "..." directory, while the hidden source of the attack program in this directory, enter / var / tmp / ... / directory, found some rootkit files are listed intruder placement, are listed below:
[the webserver the root @ ...] # / mnt / bin / LS -Al
drwxr XR-2 X-On Sep 29 4096 22:09 the nobody the nobody APA
-rw-r-- R & lt-0. 1 the nobody the nobody On Sep 29 22:09 apa.tgz
XR-2 X-drwxr the nobody the nobody On Sep 29 4096 22:09 caca
drwxr XR-2 X-On Sep 29 4096 22:09 the nobody the nobody haha
-rw-r--. 1-R & lt 0Sep 29 22:10 kk.tar the nobody the nobody. GZ
-rwxr XR-X-0. 1 the nobody the nobody On Sep 29 22:10 Login
-rw-r-- R & lt-0. 1 the nobody the nobody On Sep 29 22:10 login.tgz
-rwxr XR-X-0. 1 On Sep 29 22 is the nobody the nobody : 10 z
analysis of these documents, the basic procedure is the source of the attack is determined that we are looking for, wherein:
Z procedure is used to purge the system log, and other related information, such as performing: ./ z 62.17.163.186 this command after all 62.17.163.186 system-related logs will all be cleared.
There is a backdoor t in apa directory, this is seen before in the system after running this program, this program will automatically read this file under apa ip directory, the file record ip ip address a variety of information , t guess this should be a program to scan all files ip ip information recorded, and then obtain the rights to the remote host, showing that the web server is already a broiler of the intruder.
haha directory placement is used to replace the system-related commands program, which is a program under this directory so that we can not see the abnormality of the operating system.
login procedure is used to replace the Trojans system login program, this program can also record login ID and password.
5, find the cause of the attack
Up to this point, the server suffered attacks have mostly clear, but the intruder is how to hack this server do? This question is very important, we must find the root cause of the invasion, in order to block the underlying vulnerability.
To figure out how the intruder is entering the server, you need to understand the software environment for this server, this server is a java-based web server, software installation has apache2.0.63, tomcat5.5, apache and tomcat
by mod_jk between module integration, apache opening port 80, due to the tomcat port is not open, it will focus on the issue to the apache above.
Apache configuration found by looking, apache deal with only some static resource requests, but also static web pages majority, so the system is not the possibility of invasion by a web page, since the vulnerability may come from apache, then try to view apache log, may be able to find some suspicious traces of access, by looking at the access.log file, find the following information:
62.17.163.186 - - [29 / Sep / 2013: 22: 17: 06 +0800] "GET
http://www.xxx.com/ bin-cgi / awstats.pl configdir = | echo; echo; PS the AUX ± 00%?
HTTP / 1.0 "200 12333" - "" Mozilla / 5.0 (Windows; U; Windows NT 5.1; pt-BR;
rv: 1.8. . 1) the Gecko / Firefox 20.12101 million / 2.0 "
62.17.163.186 - - [29 / On Sep / 213: 22 is:. 17: 35 +0800]" the GET http://www.xxx.com/cgi-
bin/awstats.pl?configdir=|echo;echo;cd+/var/tmp/…/haha;ls±a%00 HTTP/1.0"
200 1626 “-” "Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1)
Gecko / 20121010 Firefox / 2.0 "
At this point, the root causes of vulnerabilities discovered, turned out to be a loophole awstats.pl script configdir by understanding the application server, the client really do web access statistics through open source plug a Awstats by this vulnerability, an attacker can operate directly on the server browser, such as viewing process, create directories, etc.
can be seen above the second log attacker normal browser to perform a handover to / var / tmp / ... / haha directory the operation of this scripting vulnerability very terrible, but in Awstats official website has long given method of repair for this vulnerability repair method is very simple, open awstats.pl file, find the following information:.
IF ($ QueryString = ~ / configdir = ([^ &] +) / I)
{
$ = & DirConfig DecodeEncodedString ( " Katex the parse error: the Expected 'the EOF', GOT '}' AT position. 6:. 1");} can be modified as follows: IF ( the QueryString = ~ / configdir = ([^ &] +) / I)
{
$ = & DirConfig DecodeEncodedString ( "$. 1");
. ~ $ DirConfig = TR / A-Z0-9 _- / / A-Z0-9 _- / / CD. ;
}
6, opened mystery
Through the above analysis and the gradual introduction of this service and the reasons for the invasion process has been very clear, roughly as follows:
(1) the attacker entered the system through a vulnerability Awstats awstats.pl script file, created under / var / tmp directory a hidden directory, then the backdoor rootkit files to this directory.
(2) a backdoor attacker, the acquisition system superuser privileges, then control of this server, this server by contracting out.
(3) the attacker's IP address 62.17.163.186 may be coming through a proxy, it could be another server broiler attacker's control.
(4) In order to permanently control the attacker's machine, modify the information systems default account mail will mail login account becomes available, and set a password mail account.
(5) Upon completion of the attacker attacks by backdoor automatic cleaning system access logs, to destroy the evidence.
Through the analysis of the invasion process, we found means an intruder is still very simple and common, although the intruder deleted some of the logging system, but still left a lot of traces can be found, in fact, can also look at user .bash_history file, this file is the history of user operations command.
7, how to restore the site
Since the file system has been changed and replaced, this system has become thoroughly discredited, it is recommended that the site data backup, reinstall the system, the basic steps are as follows:
install stable version of the operating system, delete the system default and does not require the user.
System login mode to public key authentication, password authentication to avoid defects.
Install a later version of apache and the latest stable version of Awstats program.
Use Tcp_Wrappers firewall under Linux, limit the source address ssh login.
