Some broken thoughts about the Linux intrusion response

Nearly half a year to do a lot of emergency response projects, targeted at hackers invasion. But I'm tired of not having time to summarize some of the things that are commonly used, and hope to use this blog post to share some of the common routines that security engineers are dealing with in response to emergencies, because there are a lot of possible offal.

Personally, the core of the intrusion response is no more than four words, the clues. We often need to find more critical information after some instructions to query or analyze the log, the step-by-step analysis of the hacker's specific steps.

• Linux system logs that need to be followed after an intrusion

Var/log/cron    Records whether the crontab command is executed correctly and is generally deleted by hackers

Var/log/lastlog log logged in user, can use the command Lastlog to view, generally will be deleted by hackers

Var/log/secure record most of the application entered the account and password, login success or not, will generally be deleted by hackers

Var/log/wtmp Record Login System successful account information, equivalent to the last command, the general will be deleted by hackers
Var/log/faillog Record Login System unsuccessful account information, will generally be deleted by hackers

~/.bash_history  vital logs, often hackers use history-c to clean up related logs, and then use cat ~/.bash_history to still see related records

• Web server logs that require attention after an intrusion

　　There are many kinds of Web servers, more contact for Apache, Tomcat, Nagix-based. Whatever the Web server actually needs to pay attention to is the same thing, namely Access_log and Error_log. Usually after the IP address is determined, by:

Find. Access_log |grep xargs IP attack address

Find. Access_log| grep xargs Trojan file name

is a good way to troubleshoot, through the data in Access_log and error_log we can generally clear the following several things:

1. When a file is uploaded, it is important to determine the attack point at which the attack occurred in an emergency response. Through the point of time can effectively find the encryption Trojan, hidden back door and so on. To illustrate:

Today is November 7, 2016, I found out that the attack point occurred on November 5. Stand in the site upload directory:

Find. -name *.php-ctime-1

To match the file with some more complex regular:

Find./-name "*.php"-type f-print0|xargs-0 egrep "(Phpspy|c99sh|milw0rm|eval\ (Gunerpress|eval\ (base64_decode|spider _BC) "|awk-f: ' {print $} '

Specific-ctime,-atime,-mtime no longer repeat. For the-I question, quote:

     -mtime N: N is a number, meaning a file that has been changed in "One Day" before the nth day;
     -mtime +n: Lists the name of the document that was changed before N days (excluding the N-day itself);
     -mtime-n: Lists the names of the documents that have been changed within n days (including the N-day itself);
0 is within 24 hours

2. What is the IP address of the attack, and of course the general situation is the springboard address TT

3. What documents were sent up?

• Commands to be entered immediately on board the server (all routines, but generally useful)

Ps-ef viewing suspicious processes

General Ps-ef can be relatively clear to see rebound shell, quoted below:

Http://www.waitalone.cn/linux-shell-rebound-under-way.html

Top processing a few times the broiler server, basically top can clearly see the use of resource-intensive services

Last login time can be with OPS staff time

Crontab-l   View routine tasks, many backdoors can complete the self-boot through crontab.

However, sometimes crontab-l does not solve the problem, usually do the following actions:

Cd/etc/crontabls

Check to see if there is a power trace:

CAT/ETC/PASSWD  most likely other users to appear ID, group ID 0, 0 case

It would be nice if there was a lsof command in the system:

Lsof-g gid   usually finds the Lib file associated with the malicious file

• Some of the tricks of the broken read

Chattr  +i   deal with a virus itself will rewrite crontab, you can use this command to lock crontab chmod to  remove some virus files need to first remove the execution permissions

When writing this blog post, look up the information and find that find can be used as well:

Find/*.jsp  -perm 4777  file for 777 permissions

Because I found that any hacker after the invasion of Linux in this step can not avoid such a joyful operation:

Yum Xxxxmkdir hehechmod 777 *.*CD hehe./xxxx

• Summarize

1. Emergency response the feeling core is to determine the time, IP finally is a malicious file. Especially time is the most important, if even the attack time can not be determined, feel really no good entry point, at least not guarantee that you have to clean the back.
2. As a side dish, studied a lot of Daniel's articles, combined with their own cases, feel the main point is so much. But the difficulty is whether you can accurately determine which is the normal file, which is the malicious file. And their own penetration and black production knowledge is complete, can accurately guess what the hacker did.
3. There are some things, such as the kernel Ah, the boot sequence of some problems, recently in the summary, there is a chance to complete.

　　　　

Some broken thoughts about the Linux intrusion response