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

How to check whether the Linux machine has been hacked

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

Share

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

The editor will share with you how to check whether the Linux machine has been hacked. I hope you will get something after reading this article. Let's discuss it together.

1. Intruders may delete the log information of the machine

You can check whether the log information still exists or whether it has been emptied. Examples 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/anaconda 4.0K / var/log/anaconda.ifcfg.log 24K / var/log/anaconda.log 28K / var/log/anaconda.program.log 64K / var/log/anaconda.storage.log

two。 The intruder may create a new file to store the user name and password

You can view / 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. Intruders may change username and password files

You can check the contents of / etc/passwd and / etc/shadow files for identification. Examples of related commands:

[root@hlmcen69n3 ~] # more / etc/passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin [root@hlmcen69n3 ~] # more / etc/shadow root:*LOCK*:14600: bin:*:17246:0:99999:7::: daemon:*:17246:0:99999:7:::

4. Check the recent successful login of the machine and the last unsuccessful login

Corresponding to the log "/ var/log/lastlog", examples of related commands:

[root@hlmcen69n3 ~] # lastlog Username Port From Latest root * * Never logged in** bin * * Never logged in** daemon * * Never logged in** copy code

5. View all users who are currently logged in to the machine

Corresponding to the log file "/ var/run/utmp", examples of related commands:

[root@hlmcen69n3] # who stone 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 machine was created

Corresponding to the log file "/ var/log/wtmp", examples of related commands:

[root@hlmcen69n3] # last test01 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 of all users of the machine (hours)

Corresponding to the log file "/ var/log/wtmp", examples of related commands:

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

8. If the machine is found to generate abnormal traffic

You can use the command "tcpdump" to crawl network packets to view traffic, or use the tool "iperf" to view traffic.

9. Can view / var/log/secure log file

Try to find information about the intruder. Example 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 ssh3 Sep 20 16:17:47 hlmcen69n3 sshd [38206]: Accepted password for stone from X.X.X.X port 9140 ssh3 Sep 20 16:46:00 hlmcen69n3 sshd [38511]: Accepted password for stone from X.X.X.X port 2540 ssh3 Sep 20 16:47:16 hlmcen69n3 sshd [38605]: Accepted password for test01 from X.X.X.X port 10790 ssh3 Sep 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 exe lrwxrwxrwx. 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.

(1) when a process opens a file, as long as the process keeps the file open, it still exists on disk 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 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/secure ls: 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/secure rsyslogd 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/4 Sep 20 16:47:21 hlmcen69n3 sshd [38511]: pam_unix (sshd:session): session closed for user stone Sep 20 16:47:21 hlmcen69n3 su: pam_unix (su-l:session): session closed for user root Sep 20 16:49:30 hlmcen69n3 sshd [38605]: pam_unix (sshd:session): session closed for user test01 Sep 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 ssh3 Sep 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=root Sep 20 17:18:52 hlmcen69n3 sshd [38789]: Failed password for root from 51.15.81.90 port 47014 ssh3 Sep 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/secure Sep 17 03:28:15 hlmcen69n3 sshd [13288]: reverse mapping checking getaddrinfo for 13764-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=root Sep 17 03:28:17 hlmcen69n3 sshd [13288]: Failed password for root from 51.15.64.137 port 59498 ssh3 Sep 17 03:28:18 hlmcen69n3 sshd [13289]: Received disconnect from 51.15.64.137: 11: Bye Bye Sep 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) Sep 17 03:28:22 hlmcen69n3 sshd [13291]: pam_unix (sshd:auth): authentication failure Logname= uid=0 euid=0 tty=ssh ruser= rhost=51.15.64.137 user=root Sep 17 03:28:24 hlmcen69n3 sshd [13291]: Failed password for root from 51.15.64.137 port 37722 ssh3 Sep 17 03:28:25 hlmcen69n3 sshd [13292]: Received disconnect from 51.15.64.137: 11: Bye Bye after reading this article, I believe you have some understanding of "how to check whether the Linux machine has been hacked". If you want to know more about it, please follow the industry information channel. Thank you for reading!

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