一次腾讯云centos服务器被入侵的处理

昨天一大早，我还没到公司呢，就收到腾讯云安全中心发来的服务器异常登录告警，登录控制台一看，ip还是美国的，一脸懵逼。由于本人之前也没有过处理服务器入侵的经验，而且这台服务器目前还没有部署商用系统，所以也就没怎么在意，照着云安全中心提示的可疑文件的位置，将其删除，就这样交差了。其实我知道这样肯定是不行的，但是确实很烦去处理这种事情。果然，下午又收到了告警。这是公司的电脑，老板很在意，刚好手上的事情忙完了，今天就特意花时间查了查，记录一下排查过程。

首先，还是上控制台，看一下告警的信息，告警显示的登录ip来自美国，登录账号竟然还是 root （感觉好牛批。之前我自己个人的服务器被入侵，还是被建了一个 test 用户进行操作的。），告警信息提示可以文件有两处：

/tmp/SzdXM 和 /usr/bin/dznqfa4

这次我没有急着把他们删除，而是先查看一下进程，果不其然，有几个对应的进程：

查看完进程，再看一下连接，发现这些进程打开了 100 多个连接，并且连接的目标ip都不同：

虽然查到了进程和连接，但这只能证明服务器确实被入侵了。但是怎么入侵的呢？其实我的 root 密码是20+位数字大小写字母和特殊符号组合密码，想来应该不会是暴力破解吧。然后想起了云服务器上的提示提高redis安全性告警，又想起了之前看到网上说 redis 任意文件写入的漏洞。于是去网上查了下 redis 的安全性问题。从下面这篇博文中得到了提示：

https://blog.csdn.net/u011574239/article/details/78892174

这篇文章中提到了 redis 的三条入侵特征：

于是我就对照这三条逐一检查：

1. 查看redis 的执行记录，查看 /root/.rediscli_history 文件，结果如下图。可以看出，确实执行了 flushall 命令（正常业务谁去执行这玩意啊）。好了，第一条应验了：

2. 查看可以键值对。这个没有查到，没查到很正常啊，都执行过 flushall 了。

3. 查看 /root/.ssh/authorized_keys 文件，确实存在一个 rsa 公钥。好了，第三条也应验了。

既然特征都应验了，那看来很可能就是通过 redis 入侵的了。既然如此，redis 配置肯定是要改了。结合上面提到的那篇博客的内容提示，我们可以对 redis 做如下修改：

1. 以低权限运行redis。为 redis 单独创建用户和主目录，配置该用户禁止远程登录；

2. 为 redis 添加密码校验；

3. 添加 redis 访问白名单，拒绝陌生ip的访问；

4. 禁止一些 redis 高危命令；

5. 修改 redis 服务端口，在安全组中关闭默认的 6379 端口；

另外，不要以为查到了原因，就可以动刀子，开始杀进程、删文件、改端口、改密码重启，然后就万事大吉了。服务器既然已经被入侵过了，说明很可能还留有其它后门。我们应该还需要检查开机自启动项和定时任务。说实话，开机自启动的那些服务，我是真看不懂都是干嘛的（这就很慌了）。幸好的是我们还有另外一台跟这一台软硬件版本完全一样的服务器，那一台没有被入侵，我就将两台服务器的开机启动项对比着看，倒是没有发现什么可疑启动项。

不过查到了定时任务有问题：

说明我们还需要删除定时任务。

从定时任务下载的文件内容看，定时任务执行时会从远程主机下载 i.sh 脚本，查看其内容：

可以看出，这个定时任务本身会下载脚本创建新的定时任务，所以为了防止死而复生，我们应该先从云控制台安全组将这个脚本的下载地址和端口拉入黑名单。同时将 redis 端口禁用掉。

排查完了，接下来捋一下思路：

1. 安全组配置，将 68.183.140.39:8000 禁止出方向访问；

2. 禁用 6379 端口；

3. 停止 redis 服务；

4. 删除定时任务；

5. 删除可疑的开机启动项（如果有）；

6. 清空 /root/.ssh/authorize_keys；

7. 停止对应的黑客进程；

8. 删除黑客文件；

9. 关闭服务器；

10. 修改服务器 root 密码；

11. 配置 ssh 设置，禁用公私钥登录（看需要）；

12. 重新配置 redis 服务，开放新的 redis 服务端口；

思路理清楚了，接下来动手操作：

1. 登录云服务控制台，修改安全组配置，禁止对黑客服务器的访问，禁止 6379 端口；

2. 停止 redis 服务：

ps -ef|grep redis

kill -9 pid

3. 删除定时任务：

crontab -r /var/spool/cron/root

crontab -r /var/spool/cron/crontabs/root

若出错：

cat /dev/null > /var/spool/cron/root

cat /dev/null > /var/spool/cron/crontabs/root

4. 清空公私钥授权文件：

cat /dev/null > /root/.ssh/authorized_keys

cat /dev/null > /root/.ssh/known_hosts

5. 停止对应的黑客进程：

ps -ef|grep dznqfa

kill -9 pid

6. 删除黑客文件：

rm -rf /usr/bin/dznqfa*

7. 上控制台，关闭服务器

8. 上控制台，修改服务器密码

9. 开机，配置 ssh ，禁用公私钥登录

10. 重新配置 redis，启动服务，开放新端口，重新部署应用

【附：参考文章】

1. 查看 Linux 开机启动项：https://blog.csdn.net/zyddj123/article/details/82497640

2. redis 安全配置，漏洞和入侵检查：https://blog.csdn.net/u011574239/article/details/78892174

3. Linux 配置取消密钥登录：https://blog.csdn.net/u013344860/article/details/80431835

4. ssh 私钥存放位置（本文无关）：https://www.cnblogs.com/liuyanerfly/p/9668426.html

5. Linux 查看连接相关命令：https://www.cnblogs.com/felixzh/p/7737160.html

6. Linux 定时任务操作：https://www.cnblogs.com/cqlb/p/9772207.html

7. 另外，我还把黑客定时任务下载的脚本拷贝下来了，也对黑客进程的连接进行了抓包（找时间分析分析哈哈，不过使用加密传输的，估计没戏），抓包命令教程：

https://blog.csdn.net/chinaltx/article/details/87469933

https://www.runoob.com/linux/linux-comm-tcpdump.html

好了，下班~