应该咋办？怎样知道这程序是怎样启动的，有什么应对措施？

中毒了 是挖矿的 查下那个进程名

进程名是 vTtHH

是通过定时任务跑的，暂时解决办法是把定时任务功能关掉。永久解决办法是备份数据重新安装系统

用户列表如下，有没有可疑的用户？
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
polkitd:x:999:997:User for polkitd:/:/sbin/nologin
libstoragemgmt:x:998:996:daemon account for libstoragemgmt:/var/run/lsm:/sbin/nologin
abrt:x:173:173::/etc/abrt:/sbin/nologin
rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin
ntp:x:38:38::/etc/ntp:/sbin/nologin
postfix:x:89:89::/var/spool/postfix:/sbin/nologin
chrony:x:997:995::/var/lib/chrony:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
tcpdump:x:72:72::/:/sbin/nologin
syslog:x:996:994::/home/syslog:/bin/false
centos:x:1000:1000:Cloud User:/home/centos:/bin/bash
www:x:1001:1001::/home/www:/sbin/nologin
mysql:x:1002:1002::/home/mysql:/sbin/nologin
git:x:1003:1003::/home/git:/bin/bash

more /var/log/cron log 查一下日志

太真实了，早上在 V2EX 回帖宣传一下网站，就被人暴力破解了


/var/log/cron
::::::::::::::
Aug 10 11:30:01 VM_0_12_centos CROND[18805]: (root) CMD (/usr/local/qcloud/stargate/admin/start.sh >
/dev/null 2>&1 &)
Aug 10 11:31:01 VM_0_12_centos CROND[18864]: (root) CMD (/usr/local/qcloud/stargate/admin/start.sh >
/dev/null 2>&1 &)
Aug 10 11:32:01 VM_0_12_centos CROND[18918]: (root) CMD (/usr/local/qcloud/stargate/admin/start.sh >
/dev/null 2>&1 &)
Dec 10 15:23:19 VM_0_7_centos crond[869]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 13% i
f used.)
Dec 10 15:23:19 VM_0_7_centos crond[869]: (CRON) INFO (running with inotify support)
Dec 10 15:23:25 VM_0_7_centos crontab[3078]: (root) LIST (root)
Dec 10 15:23:25 VM_0_7_centos crontab[3074]: (root) REPLACE (root)
Dec 10 15:23:26 VM_0_7_centos crontab[3185]: (root) LIST (root)
Dec 10 15:23:26 VM_0_7_centos crontab[3193]: (root) LIST (root)
Dec 10 15:23:26 VM_0_7_centos crontab[3190]: (root) REPLACE (root)
Dec 10 15:23:27 VM_0_7_centos crontab[3594]: (root) LIST (root)
Dec 10 15:23:27 VM_0_7_centos crontab[3593]: (root) REPLACE (root)
Dec 10 15:24:03 VM_0_7_centos crond[869]: (root) RELOAD (/var/spool/cron/root)
Dec 10 15:24:03 VM_0_7_centos CROND[10075]: (root) CMD (/usr/local/qcloud/stargate/admin/start.sh >
/dev/null 2>&1 &)
Dec 10 15:24:06 VM_0_7_centos crontab[10117]: (root) LIST (root)
Dec 10 15:24:06 VM_0_7_centos crontab[10121]: (root) LIST (root)
Dec 10 15:24:06 VM_0_7_centos crontab[10120]: (root) REPLACE (root)
Dec 10 15:24:06 VM_0_7_centos crontab[10147]: (root) LIST (root)
Dec 10 15:24:06 VM_0_7_centos crontab[10149]: (root) REPLACE (root)
Dec 10 15:25:01 VM_0_7_centos crond[869]: (root) RELOAD (/var/spool/cron/root)

usr/local/qcloud/stargate/admin/start.sh 是这个脚本不 你看下这个的内容


/bin/sh
create by hetiulin
umask 0022
unset IFS
unset OFS
unset LD_PRELOAD
unset LD_LIBRARY_PATH
export PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
if [ -w '/usr' ]; then
myPath="/usr/local/qcloud/stargate"
else
myPath="/var/lib/qcloud/stargate"
fi
agent_name="$myPath/sgagent"
check_user()
{
if [ "root" != "`whoami`" ]; then
echo "Only root can execute this script"
exit 2
fi
}
check_alive()
{
status=`ps ax | grep "$agent_name" | grep -v "grep" |wc -l`
if [ $status -ne 0 ]; then
process exist
echo "stargate agent already exist"
exit 1
fi
}
Main Begin />check_alive
cd $(dirname $0)
$agent_name -d
ret=$?
if [ $ret -eq 0 ]
then
echo "stargate agent run succ"
else
echo "stargate agent run failed, errcode: $ret"
fi
exit $ret
Main End ###

不是这个 这个只是腾讯云监控脚本

去看看定时任务有没有什么奇怪的

https://www.anquanke.com/post/id/171523 按照这个来看看能不能成功吧

被黑了，第一步是重装系统，第二步是看哪里没做好。

重装电脑了，吸取经验，root 密码用强密码，关掉 22 端口

好像有点暴力 关闭 ssh

关 22 不代表关 ssh 啊

你得先确定是不是被 ssh 被暴力破解啊
你说宣传了网站被黑也有可能是你的网站后端程序有越权漏洞
不过已经重装了也晚了
建议这个也检查一下

redis mysql 都不要对外开放接口

看看 redis 里有没有 cron 任务

用 private key 登陆也被破？

redis mysql 等开源 /闭源的大软件一堆 只要开了端口就能被 fuck 的 0day 漏洞。

https://medium.com/servers-101/how-to-secure-your-linux-server-6026cfcdefd8
这个链接分享给大家，希望有用

分享个人了链接之前要做好个人网站防护

密码还能开？全改密钥呀

首先装个 htop 用 tree，看看这个进程是谁启动的，pstree 也行。找到后再思考怎么处理。

只能查进程 找 shell 了

还好我的小服务器在反代后面，路由器还有 pfsense

害怕。。。我的服务器就跑了一个脚本，记录所有用户执行的命令，这样出了问题就好查一些了。

还用什么强密码，应该禁止密码登录，改成密钥。

挖矿木马大多是利用中间件的漏洞，只要被扫描到马上就会被感染，暴力破解 ssh 密码的概率比较小的。建议楼主把 cve 补丁都打全

软件系统及时升级，所有业务服务都不要 root 权限启动，非业务端口尽量全加防火墙关闭或限制外部访问，并且最好改到高位不常用端口上。

redis 没有设置密码吧？被矿了，我周二也遇到了，https://blog.netlab.360.com/systemdminer-propagation-through-ddg/

之前有台生产服务器被挖矿了， 也是一直杀不掉。
最后追踪和分析脚本发现这个程序会不断的生成一个挖矿程序（ bash ）脚本并运行， 而且二者还会相互唤起。

我最后的解决方案就是把 bash 脚本的权限设置为不可编辑状态，那么在生成的时候就会直接报错，这样就阻止了相互唤起， 剩下的就是清理程序和定时任务。

最后： 生产服务器还在跑， 也没有重装，但是把一些安全漏洞修复了。

总结：
主要问题也是对方的脚本有漏洞，生成脚本之前没有检查可编辑状态。能找到这种漏洞也是看人品了，如果自己解决不了，那么就直接重装吧

rkhunter --checkall 检查下看看

长了一波知识

先看 crontab 哇

被黑经历，分享一篇文章 ，也许对你有帮助 https://www.jianshu.com/p/97b9dc47b88c

哈哈，莫名想笑

。。。 你被启动了定时任务。

这么真实得嘛

redis 无密码？

1、查找异常的定时任务，删除攻击脚本
2、查看 /boot 下的异常文件，并删除

详细请看 http://www.91ri.org/12348.html

rootkit 很难彻底清理干净
建议备份数据+重装系统

遇到了类似的情况，供参考： https://zhuanlan.zhihu.com/p/65023864