昨晚，在可视化平台上，查看服务器监控情况，发现服务器CPU100%运行一天多了。因为是自己的测试服务器，拿来玩的，没有运行什么项目，所以，也没有经常看。发现100%，这是个问题啊，看来有事儿要做了！
排查步骤：
1. top 命令查看服务器运行情况
上图显示：qW3xT.2 进程CPU运行始终保持在98%以上，这个就是问题所在啊。kill 9392 杀死该进程。如上图所示，CPU的负载立马下来了，但是没过多久又重新回归100%。显然，有守护进程在唤醒它。
2.查找该文件存在什么地方 find / -name qW3xT.2
发现 目前有且仅有存在 /tmp/qW3xT.2 (这段话严谨吧，严格按照交大博士的公式来写的，此处应该有笑声)
发现文件之后，果断删除。此时，怀疑外部植入是通过什么方式，是如何实现守护进程的。
1.定时任务 是关键。
3. crontab -l 查看定时任务
果然，有一个陌生的计划任务，于是访问该链接
4. 访问该链接
分析这个 shell 脚本：
a.下载文件，日志写入 /var/spool/cron/root
b. ddgs.3013 也是问题文件。
上述文件删除，定时任务取消该任务。
5.解决善后问题：
A.如何植入的，通过什么提权的？ 查看他写入的日志文件 发现redis 关键字。恍然大悟
redis 在允许公网访问的时候，暴露6379的端口号，并且没有任何防范，裸奔。redis入侵也是最简单的一种。
Redis 默认情况下，会绑定在 0.0.0.0:6379，这样将会将 Redis 服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。攻击者在未授权访问 Redis 的情况下可以利用 Redis 的相关方法，可以成功在 Redis 服务器上写入公钥，进而可以使用对应私钥直接登录目标服务器。
发现问题了，自己玩的服务器也不要裸奔了，穿上衣服再出门吧。
1.redis 的bind 设置白名单 bind 127.0.0.1 (不再使用 bind 0.0.0.0)
2.修改redis的端口号 6378 (不再使用 6379)
3.添加 登录密码 requirepass mypassword
继续优化，通过shell脚本，把改删除的文件删除了之后。检查 /root/.ssh 下边是否被修改过 authorized_keys ，或者新建。如果有则校正或删除。
挖矿脚本详情看：
https://blog.netlab.360.com/ddg-mining-botnet-jin-qi-huo-dong-fen-xi/
我为人人，人人为我；美美与共，天下大同；