一次服务器被黑的全过程排查和思考

来源 | HelloCoder，作者 | HaC

前一阵子腾讯云搞活动，我买了个轻量级的服务器，部署了自己的网站。

一切都井然有条地进行中。

直到某天清晨，我一如既往地打开我的网站，发现网站竟然打不开了。

于是我进行了一系列的排查。

1、排查日志

第一时间想到的就是登录服务器，查看异常登录的日志。

好家伙，我发现服务器竟然无法登录了！

1）VNC 登录服务器

第一时间想到的应该是密码登录被禁用了。

于是我在腾讯云后台使用 VNC 登录。

无法通过客户端 SSH 远程登录时，可以通过 VNC 登录服务器。

2）查看 sshd_config 文件

查看了 /etc/ssh/sshd_config 文件后，发现果然是被修改了：

PasswordAuthentication no #表示不允许密码登录

禁用了密码登录，那应该就是被使用私钥登录了。

先改成 yes，然后重启 sshd。

systemctl restart sshd

3）使用终端重新登录

修改完之后，在本地使用终端工具重新登录，因为 VNC 登录工具实在太难用了。

发现可以登录了。

查看 authorized_keys 文件。

 vi /root/.ssh/authorized_keys

好家伙，不讲码德！

给我的服务器加了秘钥对：

4）查看登录日志

使用 last 和 history 命令，查看一下登录日志和操作日志。

last #查看所有登录的ip

history  #查看操作的命令记录

发现并没有异常的 IP，这倒是不奇怪，假如真的被登录了，登录日志被删除的可能性也是很大的。

再用 lastb 命令查看一下。

lastb #用于列出登录系统失败的用户相关信息

图一图二

lastb 结果解释如下：

第一列：用户名第二列：终端位置第三列：登录ip或者内核第四列：开始时间第五列：结束时间（still login in 还未退出  down 直到正常关机 crash 直到强制关机）第六列：持续时间

以上结果表示，服务器被暴力撞库了。

IP 应该是通过代理的，第二张图对方直接使用 root 作为用户名不断地去撞库，看来是找对了用户名，最后真的是登录了，然后修改了我的秘钥对。

查一下 IP：

IP 是国外的，很难查到位置，也有可能是代理 IP。

2、找到木马文件

1）使用 top 命令看一下

普通的 top 命令根本无法显示木马进程，看起来像是很正常的样子，因为 top 命令很可能已经被入侵者修改。

普通 top 命令

2）busybox 命令

运行busybox top可以看到隐藏的占用 CPU 的进程，原始的top已经被修改，不能显示病毒的进程，必须在busybox中执行。

下载腾讯云给的排查工具 busybox。

[root@VM-8-8-centos ~]# wget https://tao-.cos.ap-chengdu.myqcloud.com/busybox--2020-12-14 15:12:59--  https://tao-.cos.ap-chengdu.myqcloud.com/busyboxResolving tao-.cos.ap-chengdu.myqcloud.com (tao-.cos.ap-chengdu.myqcloud.com)... 132.232.176.6, 132.232.176.7, 139.155.60.205, ...Connecting to tao-.cos.ap-chengdu.myqcloud.com (tao-.cos.ap-chengdu.myqcloud.com)|132.232.176.6|:443... connected.HTTP request sent, awaiting response... 200 OKLength:  (978K) [application/octet-stream]Saving to: ‘busybox.1’100%[======================================>] 1,001,112   1.36MB/s   in 0.7s[root@VM-8-8-centos ~]# cp busybox /usr/bin/[root@VM-8-8-centos ~]# busybox top-bash: /usr/bin/busybox: Permission denied[root@VM-8-8-centos ~]# cd /usr/bin/[root@VM-8-8-centos bin]# chmod 777 /usr/bin/busybox[root@VM-8-8-centos ~]# busybox top

抓到了木马文件：

busybox top命令

以上看到 CPU 占用率达到了近 100%，挖矿无疑了。

最后和腾讯云的技术一起排查了大半天，终于揪出了以下几个木马文件，目录如下：

/tmp/.X25-unix/.rsync/c/tsm64/tmp/.X25-unix/.rsync/c/tsm32/tmp/.X25-unix/.rsync/a/kswapd0/usr/bin/systemd-network/usr/bin/kswaped

最后锁定这个挖矿进程名称是 pamdicks，接下来把木马进程杀掉，然后把木马文件删除，应该就可以了。

如果不输入全称，ls、ll、lsattr 文件查看命令是根本不会显示这个木马文件的：

无法显示木马文件，需要全名才行

删除前看看这个挖矿的进程究竟是啥：

ls -lh /proc/5445/fd top -H -p 5445

这个 pamdicks 进程有 6 个子线程：

最后追踪到是个二进制文件，触及到知识范围了，无法打开，就直接删除吧。

3、删除木马文件

1）修改authorized_keys

先把 authorized_keys 文件的公钥删除。当我执行 rm 命令的时候，入侵者把我的 authorized_keys 文件加了 +i 锁，不允许删除，so sad：

chattr +i /etc/authorized_keys    表示文件不能删除，不能更改，不能移动

真的是不讲码德，把我服务器的 chattr 命令也删除了，服务器被黑，删 chattr 命令是常见的操作。

果真找不到 chattr 命令了：

只能手动把 chattr 装回来，centos 安装过程：

yum install e2fsprogs

安装成功：

[root@VM-8-8-centos run]# which chattr/usr/bin/chattr

清空 authorized_keys 文件：

[root@VM-8-8-centos .ssh]# chattr -i authorized_keys[root@VM-8-8-centos .ssh]# echo > authorized_keys[root@VM-8-8-centos .ssh]# cat authorized_keys

2）执行 rm 命令，删除木马文件

kill 掉并删除发现的木马文件：

[root@VM-8-8-centos .ssh]# kill -9 5445[root@VM-8-8-centos .ssh]# chattr -i /usr/bin/pamdicks[root@VM-8-8-centos .ssh]# rm /usr/bin/pamdicksrm: remove regular file ‘/usr/bin/pamdicks’? y[root@VM-8-8-centos .ssh]# rm /tmp/.X25-unix/.rsync/c/lib/64/tsmrm: remove regular file ‘/tmp/.X25-unix/.rsync/c/lib/64/tsm’? y

删除之后 CPU 使用率就降下来了：

木马文件清理完毕，最后把服务器禁用密码登录，改用生成好的秘钥对登录。

暂时告一段落。

4、找到攻击的源头——Redis

过了几天，打开 Redis 的时候，发现 Redis 出现了奇怪的键值。

之前没有留意到这个问题。

Redis 被黑

大意了！Redis 开放了端口而且没有设置密码。

虽然看不懂这串东西是如何注入到我的服务器的。但是这个 crackit 的键很奇怪。

网上找到了以下资料：

Redis Crackit 漏洞：黑客远程访问 redis 服务，清空 redis 数据库后写入他自己的 ssh 登录公钥，然后将 redis 数据库备份为 /root/.ssh/authotrized_keys。这就成功地将自己的公钥写入到 ssh 的 authotrized_keys，无需密码直接 root 登录被黑的主机。

那就是说，极有可能我的服务器并不是被暴力撞库登录的，而是把 Redis 作为切入点被攻击了。

使用 top 命令看一下，我去！木马文件又起来了，看来这个 Redis 的键值不清理，木马文件还是会继续下载、执行。

kswapd0 伪装的木马

这个 kswapd0 有点熟悉。

kswapd0 占用过高是因为物理内存不足，使用 swap 分区与内存换页操作交换数据，导致 CPU 占用过高。

但是，这个 kswapd0 是个障眼法，背后的命令却是执行木马文件 /tmp/.x25-unix/.rsynckswapd0。

所以说这个 Redis 没有解决，入侵者下次还是会继续利用 Redis 的漏洞继续入侵你的服务器。

真正意义上的 kswapd0  进程却是这样的：

这才是正常 kswapd0

为了重现这个过程，我把 Redis 的值的命令执行了一遍：

[root@VM-8-8-centos ~]# ping d.powerofwish.comPING d.powerofwish.com (193.160.32.164) 56(84) bytes of data.

下载的是一个 pm.sh 脚本，打开这个脚本：

可以看到这个 sh 脚本，本质是下载一个 png 文件，而且赋予了可执行权限。

我直接也把这个 png 文件下载下来，赋予权限，然后执行， ./png。

看到有一个伪装的 bin 脚本，先删除后写入到 /usr/bin 目录。

然后不断不断地刷~ 期间 chattr 命令被删除、authorized_keys 文件被修改。

最后应该是执行 /usr/bin/kswaped 这个脚本，开始挖矿。

再用 top 查看一下 CPU，瞬间飙到接近 100%。

抓包看看：

tcpdump -i eth0 ((not port 45695) and (not host 127.0.0.1) and  (not host 183.60.83.19))

发现这个 104.27.129.57 是美国的 CDN 节点，顺藤摸瓜，把抓到的包导出到 WirteShark 看看：

红色部分就是源 IP 了，还有就是对方有请求数据库的操作（3306 端口）。

也有可能我的服务器只是一个 DDoS 攻击节点 。所以为了维护网络安全，还是要及时处理木马文件。

分布式拒绝服务攻击（英文意思是 Distributed Denial of Service，简称 DDoS）是指处于不同位置的多个攻击者同时向一个或数个目标发动攻击，或者一个攻击者控制了位于不同位置的多台机器并利用这些机器对受害者同时实施攻击。由于攻击的发出点是分布在不同地方的，这类攻击称为分布式拒绝服务攻击，其中的攻击者可以有多个。

DDos 攻击示意图

5、预防

服务器被攻击，主要的原因还是暴露的公网端口太多，特别是 Redis6789、MySQL3306 这种，还有就是服务器密码过于简单。

预防措施：

1）服务器

通过修改 /etc/ssh/sshd_config 文件：

关闭密码登录，只允许秘钥对登录。

改换 ssh 默认端口，防止暴力撞库被破解。

禁用 root 账户直接登录，开放特定的 IP 访问。

如下：

#只允许用户、IP访问AllowUsers    aliyun [email protected],[email protected].* # 拒绝 zhangsan、aliyun 帐户通过 SSH 登录系统DenyUsers    zhangsan aliyun    #使用秘钥登录AuthorizedKeysFile .ssh/authorized_keys PubkeyAuthentication yesRSAAuthentication yes#禁用密码登录PasswordAuthentication no      

2）应用

Redis 只允许本地访问，修改默认端口，不暴露给所有 IP， Redis 默认 bind 127.0.0.1 是有原因的。

MySQL 只对需要的 IP 开放访问权限。

设置端口的防火墙访问规则。

如果想要更安全，可以使用跳板机、堡垒机访问。

3）备份

定期备份数据，定期备份快照。

以上就是一次服务器被黑的排查过程和一些思考。

重磅！程序员交流群已成立

运营至今，离不开小伙伴们的支持。

为了给小伙伴们提供一个互相交流的平台，特地开通了程序员交流群

群里有不少技术大神，不时会分享一些技术要点，更有一些资源收藏爱好者不时分享一些优质的学习资料。（群完全免费，不广告不卖课！）

需要进群的朋友，可长按扫描下方二维码。

▲长按扫码