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 to do after the Linux server is hacked?

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

Share

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

This article mainly introduces what to do after the Linux server is hacked, the article is very detailed, has a certain reference value, interested friends must read it!

First of all, to calm down, drink water pressure shock. Security is always relative, and even a secure server may be attacked.

With the increasing popularity of open source products, as an Linux operation and maintenance engineer, it is very important to be able to clearly identify whether abnormal machines have been hacked. Combined with their own work experience, individuals have sorted out several common machine hacking situations for reference.

Background information: the following is viewed on the CentOS 6.9 system, similar to other Linux distributions

1. An intruder may delete the log information of the machine and check whether the log information still exists or has been emptied. Example of related commands:

[root@hlmcen69n3] # ll-h / var/log/*-rw-. 1 root root 2.6K Jul 7 18:31 / var/log/anaconda.ifcfg.log-rw-. 1 root root 23K Jul 7 18:31 / var/log/anaconda.log-rw-. 1 root root 26K Jul 7 18:31 / var/log/anaconda.program.log-rw-. 1 root root 63K Jul 7 18:31 / var/log/anaconda.storage.log [root@hlmcen69n3 ~] # du-sh / var/log/*8.0K / var/log/anaconda4.0K / var/log/anaconda.ifcfg.log24K / var/log/anaconda.log28K / var/log/anaconda.program.log64K / var/log/anaconda.storage.log

two。 The intruder may create a new file to store the user name and password. You can view the / etc/passwd and / etc/shadow files. Examples of related commands:

[root@hlmcen69n3 ~] # ll / etc/pass*-rw-r--r--. 1 root root 1373 Sep 15 11:36 / etc/passwd-rw-r--r--. 1 root root 1373 Sep 15 11:36 / etc/passwd- [root@hlmcen69n3 ~] # ll / etc/sha*-. 1 root root 816 Sep 15 11:36 / etc/shadow-. 1 root root 718 Sep 15 11:36 / etc/shadow-

3. The intruder may modify the user name and password file. You can check the contents of / etc/passwd and / etc/shadow files to identify them. Examples of related commands:

[root@hlmcen69n3 ~] # more / etc/passwdroot:x:0:0:root:/root:/bin/bashbin:x:1:1:bin:/bin:/sbin/nologindaemon:x:2:2:daemon:/sbin:/sbin/nologin [root@hlmcen69n3 ~] # more / etc/shadowroot:*LOCK*:14600:bin:*:17246:0:99999:7:::daemon:*:17246:0:99999:7:::

4. Check the recent successful login event and the last unsuccessful login event of the machine, corresponding to the log "/ var/log/lastlog", and an example of related commands:

[root@hlmcen69n3] # lastlogUsername Port From Latestroot * * Never logged in**bin * * Never logged in**daemon * * Never logged in**

5. Check all the users who are currently logged in to the machine, corresponding to the log file "/ var/run/utmp". Examples of related commands:

[root@hlmcen69n3] # whostone pts/0 2017-09-20 16:17 (X.X.X.X) test01 pts/2 2017-09-20 16:47 (X.X.X.X)

6. Check the users who have logged in since the creation of the machine, corresponding to the log file "/ var/log/wtmp". Examples of related commands:

[root@hlmcen69n3] # lasttest01 pts/1 X.X.X.X Wed Sep 20 16:50 still logged in test01 pts/2 X.X.X.X Wed Sep 20 16:47-16:49 (00:02) stone pts/1 X.X.X.X Wed Sep 20 16:46-16:47 (00:01) stone pts/0 X.X.X.X Wed Sep 20 16 still logged in test01 pts/2 X.X.X.X Wed Sep 17 still logged in

7. Check the connection time (hours) of all users on the machine, corresponding to the log file "/ var/log/wtmp". Examples of related commands:

[root@hlmcen69n3] # ac-dp stone 11.98Sep 15 total 11.98 stone 67.06Sep 18 total 67.06 stone 1.27 test01 0.24Today total 1.50

8. If you find that the machine is generating abnormal traffic, you can use the command "tcpdump" to grab the network packet to check the traffic, or use the tool "iperf" to check the traffic.

9. You can check the / var/log/secure log file and try to find the intruder's information. Examples of related commands:

[root@hlmcen69n3 ~] # cat / var/log/secure | grep-I "accepted password" Sep 20 12:47:20 hlmcen69n3 sshd [37193]: Accepted password for stone from X.X.X.X port 15898 ssh3Sep 20 16:17:47 hlmcen69n3 sshd [38206]: Accepted password for stone from X.X.X.X port 9140 ssh3Sep 20 16:46:00 hlmcen69n3 sshd [38511]: Accepted password for stone from X.X.X.X port 2540 ssh3Sep 20 16:47:16 hlmcen69n3 sshd [38605]: Accepted password for test01 From X.X.X.X port 10790 ssh3Sep 20 16:50:04 hlmcen69n3 sshd [38652]: Accepted password for test01 from X.X.X.X port 28956 ssh3

10. Query the execution script file corresponding to the exception process

A.top command to view the PID corresponding to the exception process

b. Find the executable for the process in the virtual file system directory

[root@hlmcen69n3 ~] # ll / proc/1850/ | grep-I exelrwxrwxrwx. 1 root root 0 Sep 15 12:31 exe-> / usr/bin/python [root@hlmcen69n3 ~] # ll / usr/bin/python-rwxr-xr-x. 2 root root 9032 Aug 18 2016 / usr/bin/python

11. If you confirm that the machine has been hacked and the important files have been deleted, you can try to retrieve the deleted files.

Note:

1 > when a process opens a file, it still exists on disk as long as the process keeps the file open, even if it is deleted. This means that the process does not know that the file has been deleted, and it can still read and write to the file descriptor provided to it when the file is opened. Apart from the process, this file is not visible because its corresponding directory Inode has been deleted.

2 > in the / proc directory, it contains various files that reflect the kernel and process tree. The / proc directory mounts an area mapped in memory, so these files and directories do not exist on disk, so when we read and write to these files, we are actually getting the relevant information from memory. Most of the lsof-related information is stored in a directory named after the process's PID, that is, / proc/1234 contains information about processes with a PID of 1234. There are various files in each process directory that allow applications to simply understand the memory space of the process, a list of file descriptors, symbolic links to files on disk, and other system information. The lsof program uses this information and other information about the internal state of the kernel to produce its output. So lsof can display the process's file descriptor and related file name and other information. That is, we can find information about the file by accessing the process's file descriptor.

3 > when a file in the system is accidentally deleted, as long as there are still processes in the system accessing the file, then we can restore the contents of the file from the / proc directory through lsof.

Assuming that the intruder deletes the / var/log/secure file, the method to try to recover the / var/log/secure file can be found as follows:

a. Look at the / var/log/secure file and find that it is no longer available

[root@hlmcen69n3 ~] # ll / var/log/securels: cannot access / var/log/secure: No such file or directory

b. Use the lsof command to see if any processes are currently open / var/log/secure

[root@hlmcen69n3 ~] # lsof | grep / var/log/securersyslogd 1264 root 4w REG 8 1 3173904 263917 / var/log/secure (deleted)

c. From the above information, you can see that PID 1264 (rsyslogd) opens a file with a file descriptor of 4. You can also see that / var/log/ secure has been marked as deleted. So we can view the corresponding information in / proc/1264/fd/4 (each numeric file under fd represents the corresponding file descriptor for the process), as follows:

[root@hlmcen69n3 ~] # tail / proc/1264/fd/4Sep 20 16:47:21 hlmcen69n3 sshd [38511]: pam_unix (sshd:session): session closed for user stoneSep 20 16:47:21 hlmcen69n3 su: pam_unix (su-l:session): session closed for user rootSep 20 16:49:30 hlmcen69n3 sshd [38605]: pam_unix (sshd:session): session closed for user test01Sep 20 16:50:04 hlmcen69n3 sshd [38652]: reverse mapping checking getaddrinfo for 190.78.120.106.static. Bjtelecom.net [106.120.78.190] failed-POSSIBLE BREAK-IN ATTEMPT Sep 20 16:50:04 hlmcen69n3 sshd [38652]: Accepted password for test01 from 106.120.78.190 port 28956 ssh3Sep 20 16:50:05 hlmcen69n3 sshd [38652]: pam_unix (sshd:session): session opened for user test01 by (uid=0) Sep 20 17:18:51 hlmcen69n3 unix_chkpwd [38793]: password check failed for user (root) Sep 20 17:18:51 hlmcen69n3 sshd [38789]: pam_unix (sshd:auth): authentication failure Logname= uid=0 euid=0 tty=ssh ruser= rhost=51.15.81.90 user=rootSep 20 17:18:52 hlmcen69n3 sshd [38789]: Failed password for root from 51.15.81.90 port 47014 ssh3Sep 20 17:18:52 hlmcen69n3 sshd [38790]: Connection closed by 51.15.81.90

d. As you can see from the above information, you can get the data you want to recover by looking at / proc/1264/fd/4. If you can view the appropriate data through the file descriptor, you can redirect it to the file using Icano redirection, such as:

[root@hlmcen69n3 ~] # cat / proc/1264/fd/4 > / var/log/secure

e. Check / var/log/secure again and find that the file already exists. This method of restoring deleted files is useful for many applications, especially log files and databases.

[root@hlmcen69n3 ~] # ll / var/log/secure-rw-r--r--. 1 root root 3173904 Sep 20 17:24 / var/log/secure [root@hlmcen69n3 ~] # head / var/log/secureSep 17 03:28:15 hlmcen69n3 sshd [13288]: reverse mapping checking getaddrinfo for 137-64-15-51.rev.cloud.scaleway.com [51.15.64.137] failed-POSSIBLE BREAK-IN ATTEMPT Sep 17 03:28:15 hlmcen69n3 unix_chkpwd [13290]: password check failed for user (root) Sep 17 03:28:15 hlmcen69n3 sshd [13288]: pam_unix (sshd:auth): authentication failure Logname= uid=0 euid=0 tty=ssh ruser= rhost=51.15.64.137 user=rootSep 17 03:28:17 hlmcen69n3 sshd [13288]: Failed password for root from 51.15.64.137 port 59498 ssh3Sep 17 03:28:18 hlmcen69n3 sshd [13289]: Received disconnect from 51.15.64.137: 11: Bye ByeSep 17 03:28:22 hlmcen69n3 sshd [13291]: reverse mapping checking getaddrinfo for 137-64-15-51.rev.cloud.scaleway.com [51.15.64.137] failed-POSSIBLE BREAK-IN ATTEMPT Sep 17 03: 28:22 hlmcen69n3 unix_chkpwd [13293]: password check failed for user (root) above are all the contents of the article "what to do after the Linux server is hacked" Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

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