真实记录疑似Linux病毒导致服务器 带宽跑满的解决过程

案例描述

  由于最近我在重构之前的APP,需要和server端进行数据交互,发现有一个现象,那么就是隔1~2天总会发生获取数据超时的问题,而且必须要重启服务器才能解决。早在之前,我有留意到这个问题,但是由于这个服务器目前只有我测试的时候才有访问,其他的途径的数据交互几乎没有,但是这次必须要把这个问题解决了,因为APP我肯定要上线的。

按理分析

  服务器是基于阿里云的 Linux-CentOs 6.5,由nginx解析,首先登陆阿里云官网去查看ECS云服务器的运行情况,显示的是运行中,和以往一样,费用没到期,然后在浏览器中打开官网,一样是访问不了,当时第一个想法就是带宽过载,为什么不是代码问题呢?因为不能访问是周期性的问题,肯定不是代码问题。为了确认想法,去阿里云发了次工单,请求下阿里的技术人员的帮助。

真实记录疑似Linux病毒导致服务器 带宽跑满的解决过程

 

真实记录疑似Linux病毒导致服务器 带宽跑满的解决过程

  阿里的大牛回复和我所想的一样,这时候就是进终端进一步解决了。我一般使用 XShell 软件来管理linux服务器终端的,由于外部都无法访问,那么XShell也就无法远程了,的确如此,带宽跑满,哪怕是远程终端都是不可能的。这时候由从官网进入终端。

真实记录疑似Linux病毒导致服务器 带宽跑满的解决过程

  登陆后,先用命令 sar -n DEV 1 1 查看下网卡流量的数据包和比特流等情况,1 秒 取一次值,发现是震惊的。

真实记录疑似Linux病毒导致服务器 带宽跑满的解决过程

  首先eth0 是内网卡,eth1是外网, rxpck 这个是接收的数据包,txpck 是发出的数据包,rxkB 是接收的字节, txkB 是发出的字节。发现公网在大量向外发数据包,且我上面说到,这个服务器目前只有我测试APP才有请求过来,再怎么发也不会达到19万多/s,还有这个数据会变的,有时候达到 20 万。是不是感觉有点 DDOS 的感觉,不过,rxpck 接收的并不多,这是DDOS 的几率有点低,初步怀疑是有恶意程序在大量发包。

  为了看看 eth1 到底发了多少,输入 ifconfig 回车,我擦,2点多 T 啊。

真实记录疑似Linux病毒导致服务器 带宽跑满的解决过程

  为了弄清楚是目前运行的线程有哪些,我打算采用了 nethogs 这个工具,它可以监控进程实时的流量,可悲剧的是,在这之前没安装它,然后就打算当场安装,然而,当我采用 yum install nethogs 安装的时候,发现一直处于超时(time out)的情况,ping 了下百度,发现延时很高。果然,肯定受当前的情况影响。

真实记录疑似Linux病毒导致服务器 带宽跑满的解决过程

真实记录疑似Linux病毒导致服务器 带宽跑满的解决过程

  既然查不了线程的实时流量,只能查看当前的进程了,输入 ps -ef ,看到有一个名为 vcers 的程序占用 CPU 利用率高达 34% +

真实记录疑似Linux病毒导致服务器 带宽跑满的解决过程

   ls 一下,在 root 目录,再 find -name “vcers” ,发现只有这么一个

真实记录疑似Linux病毒导致服务器 带宽跑满的解决过程

解决问题

  猜想,可能是它在大量发包, 于是直接  kill -TERM PID号 杀掉了 vcers 的进程,再 sar -n DEV 1 1 看下,恢复正常

真实记录疑似Linux病毒导致服务器 带宽跑满的解决过程

  刷新下APP,有数据了,再打开下官网链接,正常访问。赶紧下载了 nethogs 以防万一,最后再打印下 进程信息,确认 vcers 没再运行, 下次再出现的话,若还过载,就彻底删除 vcers 的可运行程序。

真实记录疑似Linux病毒导致服务器 带宽跑满的解决过程

如果您认为这篇文章还不错或者有所收获,您可以通过扫描一下下面的支付宝二维码 打赏我一杯咖啡【物质支持】,也可以点击右下角的【推荐】按钮【精神支持】,因为这两种支持都是我继续写作,分享的最大动力


真实记录疑似Linux病毒导致服务器 带宽跑满的解决过程
上一篇:OAuth2


下一篇:阿里云MaxCompute香港开服 将引入更多人工智能服务