nc命令检查22端口是否开放,返回拒绝,然而如果端口没有开的话应该返回timeout,refused代表sshd进程没起来或者已经挂掉了。
docker中安装了redis和mysql,容器都起不来:
Error response from daemon: failed to create shim task:
OCI runtime create failed: runc create failed:
unable to start container process: waiting for init preliminary
setup: read init-p: connection reset by peer: unknown
刚开始感觉服务器被攻击了,没有往被挖矿上边想,尝试用一下解决方案处理:
把原来的公网ip解绑,绑定新的静态ip。
由于登录不进去服务器,无法进行任何操作,所以要重启服务器,让sshd系统进程启动,才能进去服务器进行操作。
在网上找到了类似的docker容器无法启动报错类似的案例《docker启动容器提示read init-p: connection reset by peer: unknown问题》
ld.so.preload是动态链接库预加载机制,也是系统提供给用户运行自定义动态链接库的一种方式,在可执行程序运行之前就会预先加载用户定义的动态链接库的一种技术。当然攻击者也可以修改动态链接器来实现恶意功能,例如修改动态链接器中默认的用于预加载的配置文件路径/etc/ld.so.preload为攻击者自定义路径,然后在里面写入待加载的恶意动态链接库。
发现/etc/ld.so.preload已经被重写,/etc/data/libsystem.so内容如下:
将动态连接库清空:
echo " " > /etc/ld.so.preload
将动态链接内容清空之后,应用程序启动问题解决了,但是观察监控cpu依旧负载比较高,网络进出流量仍然比较大。
通过top -c命令看到有个进程负载很高
在检查确认不是我们系统或者业务进程之后,尝试数次kill -9,但是进程都重新启动了,并且网上关键一搜全是挖矿的帖子,机器被挖矿无疑了。确定不是简单的强制kill进程那么简单了。
有帖子说,通过ps命令找到kdevtmpfsi的父进程,将父进程kill掉即可,但是kdevtmpfsi的父进程号是1,这个是系统进程systemd的进程号,kill掉它,系统就挂了。
通过systemctl status pid命令查看进程状态、资源占用信息以及守护进程等信息
前边有讲到kdevtmpfsi进程数次被kill之后,又重新启动,肯定和kinsing有关,那么索性直接把kdevtmpfsi和kinsing资源路径删掉,然后再把两个进程kill掉:
# 删文件
rm -rf /tmp/kdevtmpfsi
rm -rf /etc/data/kinsing
# 杀进程
kill -9 1089 30082
然而,只是平静了一会儿,发现kdevtmpfsi进程又起来了,kinsing进程也在。。。
既然被攻击了,那么可能系统自带的crontab程序也被改写了,通过crontab -l查看有哪些任务
每分钟去一个俄罗斯莫斯科的ip静默下载rm.sh脚本,并且通过管道符直接bash执行不输出任何日志。。。
等我想去下载下来脚本看看内容的时候,发现大哥已经把服务停了
从这里来看,应该对于kdevtmpfsi进程有两层防被kill保护,一个是kinsing守护进程,一个是这个crontab任务。
那么方案应该相对清晰明了了,按照如下步骤逐一按顺序执行:
可以删除任务重启系统调度:
crontab -e
#删除任务行,保存
systemctl restart crond
如果单单是这台机器,根本用不到系统调度的话,那么简单粗暴直接停掉crontab:
systemctl stop crond
先全局查找kdevtmpfsi和kinsing资源路径
find / -name "kdevtmpfsi"
find / -name "kinsing"
然后把找到的路径删掉。
找到kdevtmpfsi和kinsing进程id,然后直接kill -9
kill -9 pid pid
通过上述操作后,kdevtmpfsi和kinsing进程再也没用重新启动,通过清除挖矿程序的经历可以思考遇到类似问题如何排查,以及如何做服务器防护加固。
本文分享自 PersistentCoder 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!