【教你搭建服务器系列】（7）一次服务器被黑的排查全过程-php黑洞网

本站消息

站长简介/公众号

出租广告位,需要合作请联系站长

jjjjjjjj

2139

文章

850124

访问

+关注

分类

暂无分类

日期归档

2024-11(1)

【教你搭建服务器系列】（7）一次服务器被黑的排查全过程

发布于2021-06-07 21:41 阅读(1458) 评论(0) 点赞(21) 收藏(3)

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

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

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

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

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-1257166515.cos.ap-chengdu.myqcloud.com/busybox
--2020-12-14 15:12:59--  https://tao-1257166515.cos.ap-chengdu.myqcloud.com/busybox
Resolving tao-1257166515.cos.ap-chengdu.myqcloud.com (tao-1257166515.cos.ap-chengdu.myqcloud.com)... 132.232.176.6, 132.232.176.7, 139.155.60.205, ...
Connecting to tao-1257166515.cos.ap-chengdu.myqcloud.com (tao-1257166515.cos.ap-chengdu.myqcloud.com)|132.232.176.6|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1001112 (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/pamdicks
rm: remove regular file ‘/usr/bin/pamdicks’? y
[root@VM-8-8-centos .ssh]# rm /tmp/.X25-unix/.rsync/c/lib/64/tsm
rm: 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.com
PING 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 test@192.168.1.1,root@192.168.* 

# 拒绝 zhangsan、aliyun 帐户通过 SSH 登录系统
DenyUsers    zhangsan aliyun    

#使用秘钥登录
AuthorizedKeysFile .ssh/authorized_keys 
PubkeyAuthentication yes
RSAAuthentication yes

#禁用密码登录
PasswordAuthentication no