Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What if the Linux server is maliciously attacked?

2025-03-28 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "what to do when the Linux server is maliciously attacked". In the course of the operation of the actual case, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. Attacked phenomenon

This is a customer's portal server, hosted in the telecommunications room, the customer was informed by the telecom: because this server continues to send data packets, resulting in 100m bandwidth depletion, so the telecom cut off the network of this server. This server is a Centos5.5 version with ports 80 and 22 open to the public.

Learned from customers that the number of visits to the website is not large, so the bandwidth consumption will not be too high, and it is absolutely impossible to exhaust 100m of bandwidth, then it is very likely that the server has been attacked by traffic, so log on to the server to do detailed detection.

2. Preliminary analysis

With the cooperation of telecom personnel, the network traffic of the server is detected through the switch, and it is found that the host does have the scanning traffic of port 80, so the login system checks the open port of the system through the "netstat-an" command, but strangely, no network connection related to port 80 is found. Then use "ps-ef", "top" and other commands without finding any suspicious processes. So I wonder if the system has been implanted with rootkit.

In order to prove whether the system has been implanted into rootkit, we check the ps, top and other commands under the website server with the previously backed up commands of the same version of the trusted operating system, and find that these two commands under the website server have indeed been modified. It is concluded that the server has been hacked and installed a rootkit-level backdoor program.

3. Network disconnection analysis system

Because the server keeps sending packets out, the first thing to do is to disconnect the server from the network, and then analyze the system log to find the source of the attack. However, the system commands have been replaced, and if you continue to perform operations on the system, it will become unreliable. Here there are two ways to avoid this situation. The first method is to remove the hard disk from this server and mount it to another secure host for analysis. The other way is to copy all commands from a trusted operating system of the same version to a path under the invading server. Then specify the full path to the command when you execute the command, and the second method is used here.

We first check the login log of the system to see if there is any suspicious login information, and execute the following command:

More / var/log/secure | grep Accepted

By looking at the command output, there is a log that arouses our suspicion:

Oct 3 03:10:25 webserver sshd [20701]: Accepted password for mail from 62.17.163.186 port 53349 ssh3

This log shows that at 03:10 on October 3, a mail account successfully logged in to the system from 62.17.163.186 IP. Mail is the system's built-in account and cannot log in by default, while 62.17.163.186 IP, verified, is an address from Ireland. Judging from the time when the mail account was logged in, it was earlier than the time when the server of this website was attacked.

Then take a look at the system password file / etc/shadow and find suspicious information:

Mail:$1 $kCEd3yD6 $W1eva Y5BMPQIqf TwTVJiX1 rig 15400 0Rd 999997Rd:

Obviously, the mail account has been set a password and has been changed to be able to log in remotely. The reason for using the mail account may be that the intruder wants to leave a hidden account so that he can log in to the system again in the future.

Then continue to check other system logs, such as / var/log/messages, / var/log/wtmp are empty files, you can see that the intruder has cleaned the system log files, as to why the / var/log/secure file is not empty, it is not known.

4. Look for the source of attack

What we know so far is that a mail account has logged in to the system, but why does it cause this website server to keep sending packets? The corresponding attack source must be found. By replacing the ps command on this server to view the processes currently running by the system, a new suspect has been found:

Nobody 22765 1 6 Sep29? 4-00:11:58. T

What is this .t program? continue to execute the top command, and the result is as follows:

PID USER PR NI VIRT RES SHR S CPU MEM TIME+ COMMAND

22765 nobody 15 0 1740m 1362m 1228 S 98.3 91.5 2892:19 .t

From the output, we can see that this t program has been running for about 4 days, it is run by nobody users, and this t program consumes a lot of memory and cpu, which is also the reason why the website server reported by the customer is extremely slow. From this output, we get the process PID of the t program is 22765, and then find out where the path to execute the program is based on PID:

Enter the memory directory and view the information of the exe file in the corresponding PID directory:

[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

In this way, the complete program execution path corresponding to the process is found, which is hidden because the / var/tmp directory is readable by any user by default, and the intruder took advantage of this vulnerability to create a "…" in the / var/tmp directory. Directory, where the source of the attack is hidden, enter / var/tmp/. / directory, found some rootkit files placed by the intruder, listed as follows:

[root@webserver . . .] # / mnt/bin/ls-al

Drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 apa

-rw-r--r-- 1 nobody nobody 0 Sep 29 22:09 apa.tgz

Drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 caca

Drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09

-rw-r--r-- 1 nobody nobody 0Sep 29 22:10 kk.tar.gz-

Rwxr-xr-x 1 nobody nobody 0 Sep 29 22:10 login

-rw-r--r-- 1 nobody nobody 0 Sep 29 22:10 login.tgz

-rwxr-xr-x 1 nobody nobody 0 Sep 29 22:10 z

Through the analysis of these files, it is basically judged that this is the program attack source we are looking for, among which:

1), z program is used to clear system logs and other related information, such as execution:

. / z 62.17.163.186

After this command is executed, all logs related to 62.17.163.186 in the system will be cleared.

2) there is a backdoor program t in the apa directory, which is seen in the system before. after running this program, the program will automatically read the ip file in the apa directory, while the ip file records all kinds of ip address information. It is guessed that this t program should scan all the ip information recorded in the ip file and obtain the permissions of the remote host. It can be seen that this website server is already a broiler for intruders.

3) what is placed in the directory is the program that is used to replace the system-related commands, that is, the programs in this directory make it impossible for us to see the anomalies of the operating system.

4), login program is used to replace the system login program Trojan program, this program can also record login account and password.

5. Find the cause of the attack

So far, the attack on the server is basically clear, but how did the intruder invade the server? This problem is very important, we must find the root cause of the invasion in order to fundamentally plug the loophole.

In order to find out how the intruder entered the server, you need to understand the software environment of this server, which is a java-based web server. The installed software includes apache2.0.63, tomcat5.5,apache and tomcat integrated through the mod_jk module. Apache opens port 80 to the outside world. Because tomcat does not have an open port, the problem is focused on apache.

By looking at the configuration of apache, it is found that apache only handles static resource requests, and most web pages are static pages, so it is unlikely to invade the system through web pages. Since the vulnerability may come from apache, try to check the apache log, you may be able to find some suspicious access traces. By looking at the access.log file, you have found the following information:

62.17.163.186-[29/Sep/2013:22:17:06 + 0800] "GET http://www.xxx.com/cgi-bin/awstats.pl? configdir= | echo;echo;ps+-aux HTTP/1.0" 200 12333 "-" Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1) Gecko/20121010 Firefox/2.0 "

62.17.163.186-[29/Sep/213:22:17:35 + 0800] "GET http://www.xxx.com/cgi-bin/awstats.pl? configdir= | echo;echo;cd+/var/tmp/. / ;ls+-a 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 "

So far, the root cause of the vulnerability has been found, which turns out to be a loophole in configdir in the awstats.pl script. By understanding the application of this server, customers do web access statistics through an open source plug-in of Awstats. Through this vulnerability, attackers can directly operate the server on the browser, such as viewing processes, creating directories, and so on. As can be seen from the second log above, the attacker performs a normal browser switch to / var/tmp/. . / directory operation.

This script vulnerability is terrible, but the repair method has already been given on the official website of Awstats. For this vulnerability, the fix method is very simple. Open the awstats.pl file and find the following information:

If ($QueryString = ~ / configdir= ([^ &] +) / I)

{

$DirConfig=&DecodeEncodedString ("$1")

}

Just modify it as follows:

If ($QueryString = ~ / configdir= ([^ &] +) / I)

{

$DirConfig=&DecodeEncodedString ("$1")

$DirConfig=~tr/a-z0-9 _\-/\. / a-z0-9 _\. / cd

}

6. Solve the mystery

Through the step-by-step analysis and introduction above, the reason and process of the intrusion of this service are very clear, and the general process is as follows:

(1) the attacker entered the system through a vulnerability in the Awstats script awstats.pl file, created a hidden directory under the / var/tmp directory, and then passed the rootkit backdoor file to this path.

(2) the attacker obtains the system superuser privilege by implanting the backdoor program, and then controls the server and sends packets out through this server.

(3) the attacker's IP address 62.17.163.186 may come through an agent, or it may be another broiler server controlled by the attacker.

(4) in order to permanently control the machine, the attacker modified the information of the system default account mail, made the mail account loggable, and set the password of the mail account.

(5) after completing the attack, the attacker automatically cleans the system access log through the backdoor program and destroys the evidence.

Through the analysis of this intrusion process, it is found that the means of the intruder is still very simple and common. Although the intruder deleted some logs of the system, it still left a lot of traceable traces. In fact, you can also view the user's .bash_history file, which is the history of the user's operation commands.

7. How to restore the website

Because the system has been changed and replaced, the system has become completely untrusted, so it is recommended to back up the website data and reinstall the system. The basic steps are as follows:

(1) install a stable version of the operating system and delete the default and unwanted users of the system.

(2) the login mode of the system is changed to public key authentication, which avoids the defect of password authentication.

(3) install the later version of apache and the latest stable version of Awstats program.

(4) use the Tcp_Wrappers firewall under Linux to restrict the source address of ssh login.

This is the end of the content of "what to do when the Linux server is maliciously attacked". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report