记一次流量异常处理

简介: 前两天接到一个做开发的朋友电话,说他们客户一台服务器开机后,所有一个网段的机器上网都变慢了,他远程操作这台服务器也一卡一卡的。 我第一反应就是机器被人攻击过了,因为我之前也遇到过类似的现象。
前两天接到一个做开发的朋友电话,说他们客户一台服务器开机后,所有一个网段的机器上网都变慢了,他远程操作这台服务器也一卡一卡的。
我第一反应就是机器被人攻击过了,因为我之前也遇到过类似的现象。大概都是tomcat管理密码设置的比较弱,被人上传了一些war包,导致服务器拼命往外发包,或者是被人恶意上传了一些php文件,也是往外发送大量的数据包。总而言之,往外发送大量数据包基本都是被人攻击过啦!下面看看我是怎么处理的。
1、首先我给他一个脚本,确认一下是网卡异常流量引起。注意网卡改成你的外网网卡名称。

点击(此处)折叠或打开

  1. while : ; do
  2. time=`date "+%Y-%m-%d %H:%M:%S"`
  3. rx_before=`ifconfig eth0|sed -n "8"p|awk '{print $2}'|cut -c7-`
  4. tx_before=`ifconfig eth0|sed -n "8"p|awk '{print $6}'|cut -c7-`
  5. sleep 2
  6. rx_after=`ifconfig eth0|sed -n "8"p|awk '{print $2}'|cut -c7-`
  7. tx_after=`ifconfig eth0|sed -n "8"p|awk '{print $6}'|cut -c7-`
  8. rx_result=$[(rx_after-rx_before)/256]
  9. tx_result=$[(tx_after-tx_before)/256]
  10. echo "$time Now_In_Speed: "$rx_result"kbps Now_OUt_Speed: "$tx_result"kbps"
  11. sleep 2
  12. done
然后运行这个脚本

点击(此处)折叠或打开

  1. sh traffic.sh
执行之后我们会看到偶尔流出的流量惊人。

点击(此处)折叠或打开

  1. 2016-02-03 13:32:01 Now_In_Speed: 5kbps Now_OUt_Speed: 0kbps
  2. 2016-02-03 13:32:05 Now_In_Speed: 2kbps Now_OUt_Speed: 0kbps
  3. 2016-02-03 13:32:09 Now_In_Speed: 1kbps Now_OUt_Speed: 0kbps
  4. 2016-02-03 13:32:13 Now_In_Speed: 1kbps Now_OUt_Speed: 664567kbps
  5. 2016-02-03 13:32:17 Now_In_Speed: 6kbps Now_OUt_Speed: 657895kbps
  6. 2016-02-03 13:32:21 Now_In_Speed: 3kbps Now_OUt_Speed: 568462kbps
  7. 2016-02-03 13:32:25 Now_In_Speed: 4kbps Now_OUt_Speed: 0kbps
2、问题确定了,我们就好办了,上图我截图很少,而且我还发现了很有规律的事情,大概每二十多秒就会发出3-4个左右相当大的数据包。既然有规律那就肯定是后台有程序在运行。我查看了一下服务器是不是运行了tomcat?结果webapps目录下没有一些异常的jar包。我再查了一下是不是apache什么的,结果服务器上就只发现运行了oracle,根据自己的排查故障经验,我和朋友说了把oracle关闭。缩小故障查找范围,好确认不是oracle引起的。
3、在用ps -ef看了一下基本看不出,因为进程太多了,而且很多系统的进程我也不认识,没有看到什么异常进程。只有一个tomcat进程,kill之后一会又起来了,很奇怪。肯定是什么守护程序一直启动。
4、上面说了一开机启动就会出现这个现象,那么还肯定是启动服务或者启动脚本里面写了什么代码,结果rc.local文件也正常。那么看/etc/init.d目录下的启动脚本,有没有新增的或者可疑的?果然发现了一个functions和DbSecuritySpt文件,我将这两个文件移走,然后故障依旧。看了一下DbSecuritySpt文件里面内容:

点击(此处)折叠或打开

  1. #!/bin/bash
  2. /usr/local/apache-tomcat-6.0.44/webapps/eei/gfty
初步一看这是一个很正常的脚本文件啊!一般病毒文件都是打不开的。问了我朋友说不是他们写的,那我只能将这个文件移走,然后也很二逼似的把那个functions文件也移走了,结果他们重启机器后,告诉我服务器起不来啦!截图如下:

一看上图的报错我心想肯定是那个functions文件移走报错了。不过还好这是个虚拟机,我远程连接宿主机上。
然后在上图界面输入root密码后,执行mount -o remount rw /后将functions文件移到/etc/init.d目录下重新启动。但是重启还是报错,说要检查文件系统块文件,又执行fsck -y /dev/sda后提示重启,重启后系统正常运行。没有tomcat那个进程了,但是还是偶尔往外拼命往外发包啊!
5、我又上网查了一下很多网友说是将/tmp目录下有一些的文件里面写了PID号,但是我根据这些PID号没有找到这些进程,我把这两个文件移走了。重启系统故障依旧。而且操作很卡真的很恶心,加上我自己的笔记本一上午关机7次,应该硬件老化的原因,比较2010年买的。哎!此处心中一万个草泥马飘过。
6、又咨询了朋友说iftop工具能看的出来,我试了也不行,爆卡,后来又是是iptraf工具,这两个工具都没安装,又花了很多安装时间,结果也看不出来啊!拿一个iptraf工具我们看看,如下图所示:

7、又看了一下chkconfig开机启动有没有异常的服务,一看服务太多了,也很难发现。
8、我在想是不是每次连续发送几个大包的时候是不是那个进程也会占用很高的CPU使用率呢?再一边观察流量脚本运行的情况,一边又执行top看看是不是哪个进程导致。有一个getty进程偶尔能跑到70%多,结果一查看是有6个终端,然后关闭了多余的终端,但是还是异常。也没发现别的进程占用很高的CPU使用率。
9、最后我想用netstat -an | more测试,一个一个排查当前服务器开放端口,因为我朋友说客户也不是很懂linux,开放了很多端口暴露在互联网上。发现了一个xxxx.51545->119.147.145.221:6001异常,然后我查看了一下这个51545端口对应的进程,如下所示:

这个进程执行的正是getty命令,说明和我上面一个getty进程偶尔跑到70%多使用率,查的正好符合。我尝试将这个1587进程号kill掉,再观察一段时间脚本流出流量基本为0了,也就是正常了。也就是说这台服务器通过51545端口去连接互联网上的119.147.145.221这台服务器的6001端口,查看了这个IP地址是广东电信的。
但是事情还没有完结,上面说了肯定是开机启动程序里面运行的,而且这个目的119.147.145.221地址肯定是在病毒文件里面隐藏的。我进到/etc/rc.d目录下看了一下:

看样子每个启动级别都被人置放病毒文件啦!

都是软件连哈!不过这个文件被我第四步的时候移走了,然后我们还看到了一个可疑的selinux文件,因为它和DbSecuritySpt文件的时间戳和别的启动脚本文件不一样。这就测试你的眼睛尖不尖了哈~~

再看看这个/usr/bin/bsd-port目录下的东东哈!

赶紧删除/etc/init.d/selinux文件和/usr/bin/bsd-port目录。然后重启再试试看,系统一切正常!网卡流量也一切正常。然后修改root密码,但是很遗憾这里查不出是因为系统的漏洞还是程序的漏洞导致被恶意上传代码文件的。

故障处理总结:
1、服务器一定要尽少量的使用密码登录,最好是密钥加密码登录。
2、少开一些和业务无关的端口。
3、查问题一定要用排除法。眼睛要尖。
4、还是对系统很多脚本和进程不是很熟悉。
4、虽然解决了,但是这个机器还是被人上传过的,不确定是不是还会有一些不稳定的因素,建议最好还是重新安装系统。


目录
相关文章
|
7月前
|
前端开发 Java Spring
统一异常处理
统一异常处理
47 2
|
4月前
|
PHP 开发者 UED
PHP编程中的错误处理与异常管理
【8月更文挑战第27天】在PHP编程的世界中,错误和异常是开发者常遇到的两大挑战。本文旨在通过浅显易懂的方式,引导读者理解如何在PHP代码中妥善处理错误和异常。我们将从基础的错误处理讲起,逐步深入到异常管理的高级技巧,确保你的代码在遇到问题时能够优雅地处理,而不是崩溃。文章将用实例说明如何捕获、记录和处理这些事件,以保障应用的稳定性和用户体验。
|
SQL 前端开发 测试技术
一次纯线上接口异常的排查过程
一次纯线上接口异常的排查过程
147 0
|
Java 数据库连接 程序员
异常处理:优雅地应对程序中的问题
异常处理:优雅地应对程序中的问题
226 0
|
Java 数据库连接
异常处理一:抓抛模型
异常处理一:抓抛模型
75 0
SSB配置异常引起的问题
这篇是两个SSB配置异常导致的问题总结,第一个问题很简单,但是由于第一次看到这种log,看起来也比较蒙,另外也是没想到还能有这么弱鸡的问题;之后又遇到了另外一个SSB相关的问题,因为涉及时频域资源的确定,看起来相对来说就比较费劲,这两个都是lab问题。
全局异常处理,为代码保驾护航
全局异常处理,为代码保驾护航
42 0
|
程序员 C++ 开发者
C++异常和错误处理机制:如何使您的程序更加稳定和可靠
在C++编程中,异常处理和错误处理机制是非常重要的。它们可以帮助程序员有效地处理运行时错误和异常情况。本文将介绍C++中的异常处理和错误处理机制。
116 0
|
Java
SpringBoot异常统一处理,包括系统异常、自定义异常和参数检验异常
SpringBoot异常统一处理,包括系统异常、自定义异常和参数检验异常
385 0