服务器被攻击导致CPU100%的解决 您所在的位置:网站首页 windows任务的主机进程占用率高吗 服务器被攻击导致CPU100%的解决

服务器被攻击导致CPU100%的解决

2024-06-23 00:47| 来源: 网络整理| 查看: 265

进日收到阿里云发来的报警信息,有台大数据服务器被恶意程序攻击,导致服务器的CPU、内存增高,之前处理过这种问题,处理的办法不是很理想,隔了一段时间又出现此类问题。在此总结一下:*

【阿里云】尊敬的*****:您有服务器因攻击被限制访问部分目的端口,详细信息请看https://c.tb.cn/I3.1ynZm

导致此类事件的原因包括: 服务器的端口对外开放,黑客利用这些端口的漏洞来入侵服务器(lz就是通过Redis的6379端口进行估攻击的);

服务器的账号密码过于简单,被黑客暴力破解入侵服务器;

常见的解决方式:

连接服务器找到恶意程序进程杀掉;删掉恶意进程文件;将对应执行恶意程序的用户也清除掉;清除系统计划任务中(crontab)的恶意任务;以上都是最为基础的排查思路,都处理完后在观察一段时间服务器,用top命令查看是否还有恶意程序执行,如果还有的话可能就是其他原因导致,比如恶意程序封装在系统某个应用中,解决办法就是找到此应用删除应用重新安装即可。应用服务的端口如果不对外公开的话,建议把监听地址改成本地内网地址,就是在阿里云安全组的地方- 设置安全访问ip时指定IP;服务的默认端口也要更改;增强服务器的用户名密码的安全性,不要过于简单;系统用户要设置成/sbin/nologin禁止登陆服务器; 排除服务器上是否有定时任务、顽固脚本等问题

top指令查看cpu占用情况:

``

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uCav1zhq-1631007575697)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630914542289.png)]

尝试使用kill指令杀死对应进程,杀完之后发现对应服务依旧会重启:

kill -9 pid

在这里插入图片描述

查看服务器进程数量,进程数量偏高确实存在问题:

netstat -anp |grep tcp |wc -l

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YXf3vdML-1631007575704)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630914394442.png)]

查看系统中存在的定时任务,定时任务与占用CPU最高的服务名称相同尝试关闭定时任务

crontab -l

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Kq1BOQ60-1631007575713)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630919652018.png)]

修改定时任务的文件,删除定时任务保存。保存后发现还是会向服务中添加定时任务

crontab -e

直接停止定时任务进程,发现还是在跑那两个程序

service crond status 查看状态crondtab

service crond start 启动crondtab

service crond stop 停止定时任务crondtab

直接对定时任务文件进行操作,依旧可以看到对应的定时任务,删除

vim /etc/crontab

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uqB4gKdg-1631007575714)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630921891078.png)]

报错,文件被修改成了只读文件,增加修改权限,依旧报错

chmod 777 /etc/crontab

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cs58mYd5-1631007575719)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630922633799.png)]

使用:wq!强制保存退出后查看文件依旧变成之前的样子

经查阅资料可能是指令chattr的原因导致,使用这个指令可以达到禁止对文件进行增删改查的操作

sudo chattr -i /var/spool/cron/root

如果报错指令找不到,如下,centos下可以到下一行命令安装

报错chattr: command not found

安装sudo指令(报错找不到sudo指令的使用)

yum install sudo

centos安装命令

yum -y install e2fsprogs

如果出现以下提示,说明chattr指令已经安装,如果无法使用,说明对应的程序使用后被删除了

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-089rAkwE-1631007575723)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630934942030.png)]

此时需要将对应依赖卸载后重装

#删除对应依赖

yum remove e2fsprogs

#重新安装

yum -y install e2fsprogs

安装后可以再次执行上面的指令

安装后再次执行sudo chattr -i /var/spool/cron/root命令发现可以正常执行

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YtEXjRAZ-1631007575725)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630938080700.png)]

尝试修改root文件,将里面的定时任务删除,依旧报错"root" E212: Can’t open file for writing

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fgyo4VZY-1631007575728)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630938189527.png)]

使用lsattr 命令查看被限制修改的文件,这个目录正好是crontab任务的文件,最后一层root代表的是用户名称,如果使用czw账号设置的定时任务那需要进入到czw目录下操作

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ltE2ryKL-1631007575729)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630938610727.png)]

这里的a代表Append Only,系统只允许在这个文件之后追加数据,不允许任何进程覆盖或截断这个文件。如果目录具有这个属性,系统将只允许在这个目录下建立和修改文件,而不允许删除任何文件 这里的e 表示extent format,它表明该文件使用磁盘上的块的映射扩展。属于“正常”规则。

具体规则可参考:Linux chattr 命令详解

因此我们需要把对应文件的-a权限删除,使用如下指令删除,如果是-i权限,将下面指令换成-i即可

chattr -a /var/spool/cron/root

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YT7kZxUU-1631007575736)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630939009318.png)]

再次查看定时任务情况这时发现没有了定时任务

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xLeuyP1p-1631007575752)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630939809201.png)]

发现过了一段时间后定时任务又被添加了进去【/手动裂开】

crontab -e

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-C9la0Tl3-1631007575754)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630939111454.png)]

怀疑病毒服务中包含向程序中添加定时任务的功能,于是同时向crontab中删除定时任务和杀死crypto服务,再次查看,惊讶的发现还是不行

排除Docker镜像问题

对应定时任务与脚本问题排查了一天后感觉应该还有些其他问题,于是突然想到最近docker里面经常性运行我不认识的镜像并且与同事确认他们没有进行相关操作后,于是开始排查镜像的问题,因为我记得昨天上午我停掉了所有容器并且删除了所有已知容器,但是今天早上发现docker又无故运行了很多的镜像。这里本来花了很多的时间排查包括卸载docker,但由于怕误导大家所以把相关的排查过程删除了仅提供以下思路供大家排查问题

停止docker后再停止对应服务是否可行是否有不认识的镜像与同事确实后删除 删除系统中无用账号

感觉被限制的文件太多了实在无法处理所以打算删除系统中新增的账号,也许会有用

#查看系统中用户账号

vim /etc/passwd

这是删除之后的账号列表,之前有两个名称为 hilde、lsp的用户名,使用指令删除

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oMw5MObR-1631007575763)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630994471963.png)]

#删除用户指令如下,删除的过程中可能提示需要某些文件的权限,老规矩使用chattr删除权限

sudo userdel -r -f 用户名

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tjfDKrL6-1631007575765)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630994619440.png)]

再使用top指令查看CPU情况,发现占用CPU最高的服务有了路径,于是使用指令查看项目下是否有这个脚本的存在

#查看CPU情况:top

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pIAY2MrC-1631007575766)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630994836234.png)]

#查找对应服务位置:whereis crypto

发现/usr/share目录下确实有这个脚本,于是找到脚本打开看了一下

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3f2e7VqT-1631007575767)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630995033856.png)]

虽然不是很明白,但是可以猜测出大概的意思是如果crypto的pid进程不存在的话就执行/usr/share/crypto的脚本,否则的向日志文件追加一堆字符串

#!/bin/bash if ! pidof [crypto] >/dev/null; then nice /usr/share/[crypto] $* else echo "Monero miner is already running in the background. Refusing to run another one." echo "Run \"killall xmrig\" or \"sudo killall xmrig\" if you want to remove background miner first." fi

找到对应文件夹后发现响应的文件有很多,其中日志文件也有,根据脚本创建时间可以推测出被攻击的时间大概在9.5号

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7CurqALQ-1631007575769)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630995714541.png)]

删除/usr/share目录下可疑文件,如果不知道什么是可疑文件可以与正常服务器做对比或者让朋友发你一个他们公司正常目录下的截图

将/usr/share下文件删除后使用删除crypto服务的方法删除其他程序。使用top指令查看cpu使用情况,对于不熟悉的进程且占用资源较高的,使用 whereis 名称 指令找出对应位置后删除然后杀死对应进程(杀死进程指令:kill -9 pid),最后剩下的如下图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UCLUuBr7-1631007575774)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630997116048.png)]

最后再查看一下定时任务,发现还有一个病毒相关的定时任务,使用指令 crontab -e 删除发现无效,于是直接进入到用户的定时任务中删除

#编辑root账号的定时任务,如果定时不是root账号创建则需要将指令的最后root改成用户名

vim /var/spool/cron/root

提示:由于定时任务指令可能较长可以使用快捷键快速清除文本内容(清除文件中所有内容):%d

发现systemd-journal服务也是一个病毒,但是很多搜索指定都找不到,于是使用如下指令搜索并删除

ps -ef|grep systemd-journal

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TyGpoGW8-1631007575775)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1630999232546.png)]

找到对应的路径,删除文件

rm -rf /usr/lib/systemd/systemd-journald

删除之后服务再也起不来了,赞,直接拿捏。

报错的话基本上面的篇幅也提到过,所以应该问题不大,NB

最后需要将他们的攻击端口的服务改成其他端口即可,后期我会将公司项目架构全部修改,会出一篇新的帖子,有兴趣的可以关注一下

创作不易,如果对你有帮助希望点个爱心,耗时将近两天解决这个问题,转载请注明出处

**************************余生还长,切勿惆怅**************************

----------------------------------------20210913更新----------------------------------

经过前几天的修复,使用top指令CPU使用正常,但是发现短信依旧提示被恶意攻击,于是登录终端使用top指令查看CPU情况占用率很低,登录阿里云官方查看CPU占用情况高达100%。

在这里插入图片描述

终端截图 在这里插入图片描述 阿里云官网CPU官网截图 在这里插入图片描述

解决方法

使用指令下载htop指令

yum -y install htop

下载后执行指令htop,还可以在锁定大写情况下输入P使其按照CPU占用率进行排序

htop

发现又两个进程的CPU占用率较高 在这里插入图片描述

找到对应的脚本目录直接删除脚本再使用kill指令杀死进程,文件可能会隐藏无法在xftp中直接查看,可以找到 工具 》选项 》显示隐藏文件 打开隐藏的文件选项。删除完成之后再查看阿里云服务器上的CPU使用率此时显示正常 在这里插入图片描述

-----------------------------------------20211223更新----------------------------------------------------

前言:经过前面两次的修复之后,过了差不多十天左右,服务器CPU又到了100%。然后当我使用之前的方法时发现已经完全不好使了,经过排查发现是Redis服务的6379端口向外开放导致的,然后怀着沉重的心情把6379端口关闭之后发现对应的问题还是没有解决,然后中间两个月的时间中间偶尔上去看一下找一找解决方法都没有解决,最终今天总算是把这个问题解决了,因此来这里更新一下操作方法,希望大家以后可以快速解决问题,本来都像这样要重装系统了,哪知道柳暗花明又一村,好了看看怎么怎么解决的吧。

问题描述

出现的问题就是,不管是使用top指令还是使用htop指令都无法查看到cpu占用率很高的进程,但是在进程使用率的地方可以看到cpu的us和sy以及ni占用率加起来差不多百分之百了 在这里插入图片描述

查看文件/etc/ld.so.preload 发现里面有多个.so的文件,编辑该文件 vim /etc/ld.so.preload,删除文件中的内容 在这里插入图片描述 如果删除内容的时报错E45: 'readonly' option is set (add ! to override),可以使用指令lsattr /etc/ld.so.preload查看文件权限,再使用chattr -i /etc/ld.so.preload为文件夹赋予操作权限(-i参数取决于lsattr指令看到文件权限是什么) 在这里插入图片描述 删除文件中对应位置的脚本文件 在这里插入图片描述

再用top命令,cpu高的进程显示出来了

在这里插入图片描述

然后就可以根据进程查相关信息并解决, 通过ps -ef | gre 进程名 查询相关信息路径之类 在这里插入图片描述 杀死对应的pid 在这里插入图片描述

删除服务中出现的对应路径的文件 在这里插入图片描述

通过指令查看系统中所有用户的定时任务: cat /etc/passwd | cut -f 1 -d : |xargs -I {} crontab -l -u {} 在这里插入图片描述

最后再次查看运行情况htop 在这里插入图片描述

声明:此解决方式参考下面链接来完成的,成功解决了困扰lz几个月的问题,另外就是mark一下

友情链接:记Linux服务器CPU使用率接近100%,但是使用top看没有发现cpu占用率高的进程

另外也可以尝试下面这种方法解决,主要是通过安装nethogs工具来通过服务器与外网的交互来定位端口,个人觉得也可以使用 友情链接:阿里云服务器CPU跑满或抛高及带宽跑满怎样排查分析原因?(图文教程)



【本文地址】

公司简介

联系我们

今日新闻

    推荐新闻

    专题文章
      CopyRight 2018-2019 实验室设备网 版权所有