Yesterday morning, I have not yet to the company, they received Tencent Cloud Security Center sent to the server to log on alarm, log in to see the console, ip or the United States, and a look ignorant force. Since I have not had the experience before processing server invasion, and this server is currently no commercial deployment of the system, so it is no care how, according to the position of the cloud security center prompting suspicious file, delete it, so muddle . In fact, I know that this is certainly not enough, but really annoying to deal with this kind of thing. Sure enough, the afternoon received a warning. This is the company's computers, the boss is very concerned about, just hand things busy, and today it deliberately take the time to investigate the investigation, the record about the investigation process.
First of all, or on the console, look on alarms, log ip alarm display from the United States, or even login account root (feel good cow batch. My own personal server before the invasion, or be built to operate a test user . a), alarm information suggesting there may be two files:
/tmp/SzdXM 和 /usr/bin/dznqfa4
This time I did not hurry to delete them, but first look at the process, sure enough, there are several corresponding process:
When you finish viewing the process, let's look at the connection and found that the process has opened more than 100 connections and connecting the target ip is different:
Although the process and found the connection, but this only proves that the server indeed been invaded. But how invade it? In fact, my root password is 20+-digit uppercase and lowercase letters and special characters password combination, presumably it should not be a brute. Then think of the tips to improve the security alarm redis server on the cloud, thought of before seeing online that vulnerability redis any file written. So to check the safety issues under redis online. Get tips from following this blog:
https://blog.csdn.net/u011574239/article/details/78892174
The article mentions three of intrusion signatures redis:
So I checked one by one these three controls:
1. See recording is performed redis view /root/.rediscli_history file, the results shown below. As can be seen, indeed executed flushall command (normal business who is going to perform this stuff ah). Well, first fulfilled:
2. Review possible pairs. This is not found, not found in normal ah, we have executed a flushall.
3. Check /root/.ssh/authorized_keys file, the existence of a rsa public key. Well, the third is also fulfilled.
Since the features are fulfilled, it seems likely that the invasion by redis. That being the case, redis configuration is certainly to be changed. Essay blog content combined with the above mentioned tips, we can make the following changes redis:
1. low privileges to run redis. Create a home directory for users and redis individually configure the user prohibits remote login;
2. Add the password verification is redis;
3. Add redis access the white list, ip access refusal of strange;
4. prohibiting certain risk redis command;
5. Modify redis service port, closing the default port 6379 in the security group;
Also, do not think found the reason, it can Dong Daozi, began to kill the process, delete files, change the port, change the password to restart, and then everything will be fine. Since the server has been compromised over, it is likely to also leave the other back door. We should also need to check the boot from the startup items and timing tasks. To be honest, those services from the start of the boot, I really do not understand is why the (This is very alarmed). Fortunately, that we have another one with exactly the same version of the software and hardware of this station server, that station is not compromised, I will compare the two to see the boot entry server, did not make any suspicious startup items found.
But he found the timing of the task in question:
That we also need to remove a scheduled task.
From the contents of the file to download to see the scheduled tasks, scheduled tasks will download i.sh script is executed from a remote host, view its contents:
As can be seen, the timing of the task itself will download the script creates a new scheduled task, so in order to prevent the dead, we should start with Cloud Security Console Download this script will set the port and pulled into the blacklist. While redis port disable the swap.
The investigation is over, then stroked some ideas:
1. Safety group configuration, a direction to prohibit access 68.183.140.39:8000;
2. Disable the 6379 port;
3. Stop redis services;
4. Remove the timing task;
5. Delete suspicious startup items (if any);
6. Empty /root/.ssh/authorize_keys;
7. Stop Hackers corresponding process;
8. Delete the file hackers;
9. Close the server;
10. Modify server root password;
11. ssh configuration settings, log disable public and private key (see the need);
12. Reconfigure redis services, open new redis service port;
Thinking straightened, then hands:
1. Log cloud service console, modify the security group configuration, disable access to the hacker's server, port 6379 is prohibited;
2. Stop redis service:
ps -ef | grep Redis
kill -9 pid
3. To delete a scheduled task:
crontab -r /var/spool/cron/root
crontab -r /var/spool/cron/crontabs/root
If the error:
cat /dev/null > /var/spool/cron/root
cat /dev/null > /var/spool/cron/crontabs/root
4. Empty public and private key authority:
cat /dev/null > /root/.ssh/authorized_keys
cat /dev/null > /root/.ssh/known_hosts
5. Stop Hackers corresponding process:
ps -ef | grep dznqfa
kill -9 pid
6. Remove the hackers file:
rm -rf /usr/bin/dznqfa*
7. console, shut down the server
8. console, modify the server password
9. boot, configure ssh, disable public and private key login
10. Reconfigure redis, start the service, open a new port, to re-deploy applications
[Attachment: Reference article]
1. Check the Linux boot entry: https://blog.csdn.net/zyddj123/article/details/82497640
2. redis security configuration, vulnerability and intrusion detection: https://blog.csdn.net/u011574239/article/details/78892174
3. Linux configuration cancel key registration: https://blog.csdn.net/u013344860/article/details/80431835
4. ssh private key storage position (unrelated herein): https://www.cnblogs.com/liuyanerfly/p/9668426.html
5. Linux-related command to view the connection: https://www.cnblogs.com/felixzh/p/7737160.html
6. Linux operating scheduled task: https://www.cnblogs.com/cqlb/p/9772207.html
7. In addition, I also timed task hacker downloaded a copy of the script down, but also to connect hacker capture process carried out (ha ha find time analysis, but uses an encrypted transport, it is estimated the game), packet capture command Tutorial:
https://blog.csdn.net/chinaltx/article/details/87469933
https://www.runoob.com/linux/linux-comm-tcpdump.html
Well, after work ~