1、free -m 查看内存使用状态 ,发现free基本没了。--> 怀疑是服务有内存泄漏,开始排查
2、使用top命令观察,开启的服务占用内存量并不大,且最终文档在一个值,且服务为java应用,内存并没达到父jvm设置上限。按top监控占用内存排序,加起来也不会超过物理内存总量。查看硬盘使用量,占用20%。基本排除虚拟内存占用过大的原因。--->排除服务内存泄漏因素,怀疑mysql和nginx,开始排查
3、因为top命令看 mysql占用内存也再可控范围,是否存在connection占用过多内存,发现并不会,设置最大连接数为1000,最多也不会超过几M。 nginx占用一直非常小。但每次最先被kill的基本都是nginx进程。所以排查,但发现无非就是openfiles数量啥的调整。发现也一切正常。且之前niginx可以正常使用的。
4、最为费解的就是 通过free -m 查看的时候 基本全是used,cache部分很少,free基本没有。但top上又找不到有哪些进程占用了内存。无解
5、注意到有两个进程虽占用内存不多,但基本耗光了100%的cpu。开始想着占cpu就占了,没占内存,现在是内存不不够导致进程被kill的,就没注意这点。
6、实在搞不定,重启服务器,重启了所有服务,服务暂时可用,回家。在路上的时候发现又崩了。忐忑的睡觉。
7、早上起来继续看,这次留意注意了下那两个占用高cpu的进程,kdevtmpfsi 和 networkservice。本着看看是啥进程的心态,百度了下。真相一目了然,两个挖矿病毒。
突然后知后觉的意识到错误原因:
1、cpu占用率高,正常服务使用cpu频率较高的服务最容易最内存超标。(因为在需要使用cpu时没cpu资源,内存大量占用,服务瞬间崩溃),然后看top发现刚刚已经占用内存的进程已经被kill了,所以没发现内存有高占用的情况。
2、后面的应用继续使用cpu时也会发生类似情况,倒是服务一个一个逐渐被kill。
问题点基本定位好了,解决问题就相对简单很多:
通过百度,google,常见的病毒清除步骤基本都能解决。这两个挖矿病毒很常见,大致记录下要点。可能所有病毒都会有这些基础 *** 作。
① 首先,查看当前系统中的定时任务:crontab -l
我服务器上有四个定时下载任务 通过wget 和 curl 下载病毒文件,把异常的删掉。要不然删了病毒文件还是会下载下来
crontab -r,全部删除命令(或根据需求删除定时任务)
② 查找病毒文件 可以全部模糊搜索 清除, 但病毒文件基本都用了chattr +i命令 使用chattr -i filename 后再使用rm -f filename 。可删除
③ kill 病毒进程,但注意kill了可能马上就重启了。因为有守护进程,需要把病毒进程的守护进程也kill掉
④ 检查是否root用户被攻击,可能系统配置信息被更改。
⑤ 最好能理解病毒脚本,通过看代码看它做了些什么。针对脚本取修复系统。既然是中毒了,就杀毒呗。
首先进行全盘杀毒 *** 作,确认是否有病毒。可以尝试网络在线杀毒。
如果无法杀毒,建议使用PE系统盘启动电脑,备份重要的数据后,对硬盘进行快速分区,重建主引导记录,彻底清除可能的病毒隐患,然后重新安装系统。
系统安装完成,记得安装杀毒软件,并升级病毒库,再对备份数据杀毒。线上一台服务器,CPU高达90%以上,经过top 分析出进程kdevtmpfsi
kill -9 杀死进程无果,很快就会自动恢复
排查步骤:
结果:
病毒被植入到了线上运行的某一docker容器内。
如何先确定是哪一容器再去删除搜索结果中的病毒文件?
我这台机器跑的容器不多,可以用复制文件的方法,先 docker cp 一个文件到容器中。再去find 这个文件
如果结果还是在刚才搜索病毒的那个文件目录下(/var/lib/docker/devicemapper/mnt/xxxxx )就可以确定容器了。结果是php的容器出现了问题。
知道是具体是什么容器出现了问题,最快的办法就是先重启一个新的容器。
我这边是nginx +php 两种服务容器,所以先启动了一个新php容器,修改nginx中配置文件代理后端php服务器端口为新容器的IP地址。(nginx容器已经映射目录到宿主机)
修改PHP后端IP地址
cd 宿主机映射nginx的配置文件位置目录
测试线上环境正常后,删除原来的php容器。(这是自然也==直接删除了病毒文件)
执行 TOP命令,CPU占用正常。
平时防火墙和sellinux都关闭的话,服务器不要暴漏太多无用端口,出现问题应该最新通过进程名去查找文件的原始位置去分析问题,遇到挖矿病毒也应该多注意/etc/initd下和cron计划任务有无异常。
后期也可以写个cron或者脚本
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)