记一次应急响应

2023-05-21 126

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 记一次应急响应

0x00:前言

在某次摸鱼划水等下班的时候,突然接到一个甲方爸爸的紧急通知,一台Linux的CPU突然飙升,一直下不来.重启后还是一样的问题.简单询问后.开始了应急响应工作.

（重点：应急响应要先备份日志）

0x01:排查

一、首先查看一下云平台的告警情况

11358c2caf9a5d0f662f17a2d4606243_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

5c62956abe91485283aeffcdb472fbc6_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

4215ad9b02e1d39b60905934b74cf8d4_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

好家伙

我直呼

好家伙！！！

5c36288b86cebaf10a8925795a2cf0a6_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

d0f3caf4d5acb802a68a837c4b83a466_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

5ca0256472fe593b7dd6975bafe578dd_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

发现起因是docker API的一个命令执行漏洞引起的

这里先采用平台自带的查杀工具先查杀一下

3fbbf2f5f79d481daaaaf6923bdd91f7_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

70f9a53991e09a35c0b341da2981469a_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

都把权限维持了这么好

看来是老手了

562ce370942ef2489fde9a05079062a9_640_wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1.jpg

进一步的进行基线自动化检查

3b7bace985927ef2ca2fb245a6e38ccc_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

发现了docker 问题,另外还发现其他问题.

二.主机排查

1.计划任务排查

发现异常,百度走起

805187cc18bcb3072578c08be5d68f91_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

7babb3884f372d6db21f23540759d8e8_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

确认挖矿病毒,先删除计划任务

2.文件异常排查

a378688c037839ff41fb21066d983528_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

发现一堆符合上面的挖矿病毒的文件,反手一波 rm -rf 文件

（能瞬间让你升职加薪的那个命令）

3.启动项排查

156bbbe2fcb7d8f81ddd1112ad96d8d2_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

暂时没看到异常

4.端口排查

ce5503a290d854c33e9416e45cfbcdf6_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

发现歪果仁的IP地址

d3fb71ee650d74ee1deba26a0b26d071_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

5.docker排查

84ac7b8e38e180a9e395fc2b27dfd71b_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

嗯？

发现一堆JD脚本本来想删除

问了一下客户

是他们自己的脚本

很皮

c2af1acf809d4cc3402d1e76811ba42f_640_wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1.jpg

不过甲方爸爸

我依然爱你

ce6db9805abfc16dca8c56a84b8ab223_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

客户说只是在用一个docker镜像

这里是三个

看下文件

754f30a1c43cd8acbeccaeeffa3db5a9_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

呦西

又找到一个点

我这里把所有的可疑镜像给删除了

6.历史命令排查

72b207342c46329c18895488681f5423_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

发现对有人对计划任务进行一顿操作

百度了一下名称

9dc1abe4f8b8a6da89175d3e736377ca_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

好家伙

又是一个挖矿病毒

又反手一个删除处理

7.进程查看

573c17dd618fc0b1db1315acdfd08caa_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

发现bash占用大量的CPU

这里选择kill -9 23699

干掉它

干掉

干

8.针对docker api未授权修复

先限制一下端口不对外的问题

也可以采用限制白名单的访问模式

第三个方案是

使用TLS

9.更改服务器登陆模式

禁用账户密码的登陆,采用公钥登陆模式

# vi /etc/ssh/sshd_config
PasswordAuthentication no //禁止使用基于口令认证的方式登陆
PubkeyAuthentication yes //允许使用基于密钥认证的方式登陆
# /etc/init.d/sshd reload

10.日志查看

6a2a0a99039c44622ae7fe2036c92750_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

日志残了？

说好的我要备份日志的

没了

11.收尾

发现一个脚本文件

79bae84f7dd573c188a6814fbc1674e6_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

这..一顿瞎操作下来

服务器就...

针对服务器系统被搞残的情况下,我在了解详细客户的文件情况下,跟客户对接后.对文件进行备份后,将服务器重装了.

0x02:总结

1、在重装系统后,还是采用了公钥的等,端口不对外.docker采用TLS、白名单的访问.

2、在应急响应的时候,需要细心的发现每个进程,每个外链IP.才能从中的发现问题.

3、在跟甲方爸爸对接细节的时候需要很细心,不然甲方爸爸很容易忘事.你懂的.