借助Sniffer分析网络流量

各位作维护的同事常常会听到用户对网速太慢的抱怨，可是网速慢的缘由有不少，好比软件设置不当，网络设备故障，物理链路问题，感染病毒等，而单单从用户的故障描述里面很难有进一步的发现，因此也许你们一时也不知道从何下手。 　　
　　 Sniffer是一个很是好的流量 分析工具，利用它咱们能够实际了解到当前网络中正在发生的具体流量，而且经过 Sniffer的专家系统以及进一步对数据包的解码 分析，咱们能够很快的定位网络故障，确认网络带宽的瓶颈，在故障发生前及时消除网络隐患，这样能给咱们平常的维护工做带来很大的方便，也使得咱们的维护工做处于主动地位，不会再只有接到用户故障投诉后才能处理故障，在时间和效率上都不能很好的让用户满意。下面是借助 Sniffer对我某地市分公司出口流量作的一个简单的流量 分析，没有什么很深的技术含量，也并不须要太深的专业知识，但愿能对你们平常的维护工做有必定启发。 分析目标：了解目前带宽实际利用率，检查有无网络隐患。

　　 分析方法：

　　在核心交换机上作端口镜像，利用sniffer抓包。

　　测试时间：2005.5.17 10:00～10：10

　　测试地点：中心机房

　　抓包开始时间：5.17 10:20

　　抓包持续时间：16s

　　数据包个数：88865

　　平均带宽利用率：7％

　　1，首先咱们了解一下网络中 协议的分布状况，经过sniffer的Protocol Distribution功能能够直观的看到当前网络流量中 协议分布图：

从上面能够很明显看出，HTTP应用流量最大占63％，其次就是NetBios流量占35％。

　　了解 协议分布状况之后，咱们再找到网络中流量最大的主机，由于流量越大也就意味着对网络的影响也就越大，利用sniffer的Host Table的饼视图功能能够容易的找到流量最大的机器，以下图所示：

　　能够看到219.72.238.88，219.72.237.201这两台主机在目前咱们网络内部流量较大，分别占16.52%和15.97％。进一步利用HostTable功能的Outline视图，能够发现这两个地址流量的90％都是HTTP流量，以下图所示：

　　咱们能够从上图注意到，219.73.238.88这个主机上行流量要明显小于下行的流量，而219.72.237.201这个主机则是上行流量明显大于下行流量，经过确认219.72.238.88为一台Web服务器，219,72,237,201则是其余公司托管我在我公司的一台服务器，因此到这一步咱们就能够大体知道这两个主机当前正在进行的网络活动。 　　同时咱们要注意的就是每一个地址的收发包数量是否正常，便是否收发之间存在较大差别，若是只收不发或者只发不收，那极可能就意味着这个主机的当前流量有异常（例如受到SYN***），咱们能够进一步经过sniffer提供的Decode功能对捕获的数据包进行解码，来 分析具体的数据包内容。好比咱们经过定义一个过滤器来查看上面两个地址的具体数据流量,以下图所示：

 　　咱们能够看到在这些HTTP应用里面， TCP的三次握手都很完整，排除了恶意的SYN***行为，都是正常的HTTP流量。 　　附:也许从此次的例子看不出有什么异常，实际上在大部分的状况下一旦网络出现异常，能够在第一时间直观的经过HostTable功能找到问题的根源。 　　2，查看sniffer的专家系统，发现存在大量的Local Routing（本地路由）告警，sniffer中对此告警的解释为：Two DLC stations on the same segment are communicating via a router. Packets are being transmitted via the router rather than directly from one DLC station to the other（大体意思是两个属于同一网段的主机之间经过路由器通讯，数据包经过路由器发送而不是直接在两主机间转发）。并提示可能缘由为路由表设置不当。(以下图所示)

　经过查看告警来源，发现流量均为来自私网地址的139端口链接，经过sniffer的Protocol Distribution的Packet排序能够看出Netbios 协议流量占全部流量的80％，即当前网络中80％的数据包都是Netbios 协议数据包。以下图所示：

很明显出现这种现象是不正常的，咱们能够在所捕获的数据包里定义过滤器，选择只查看Netbios 协议，进一步了解具体的数据包内容（以下图所示）：

　　发现存在大量网内的私网地址发起的139端口链接请求，并且全都是 TCP的SYN请求， TCP的三次握手只有一次，极可能受到了SYN***。数据包大小都是62字节，并且每一个数据包之间发送间隔都在1ms内，排除人为发起 TCP请求的可能。经过观察数据包的源，目的IP地址，发现源地址很分散，目的地址均为实际并不存在的IP地址，但根据我公司IP地址规划都属于某地市分公司私网地址段。根据流量的特征，初步判断为私网用户感染蠕虫病毒，病毒经过139端口与大量虚假IP地址创建链接，形成网络中存在大量短数据包，严重下降网络运行效率。

　　同时咱们还发现当前网络对每个 TCP链接请求进行不断的重传，直到TTL值过时以后才被丢弃。经过跟踪查看某个地址的重传数据包，发现一个奇怪的现象：

　　上面两幅截图是 Sniffer捕获的172.17.60.126对172.17.46.14发起 TCP链接请求的两个数据包，能够看到在数据包的网络层里面有两个选项：Identification，Time to live（TTL）。Identification是用来惟一标识主机发出的每一个数据包的，正常状况下每一个数据包的ID都不同，而TTL是用来限制数据包在网络中通过的跳数的，每通过一跳TTL值就减1，直到TTL值为0的时候数据包就被丢弃，主要是防止当网络中出现环路时数据包的循环传送。而在上图能够看到，这两个数据包的Identification是同样，只是TTL值相差1。这就表示这两个数据包其实是同一个数据包（由于ID同样），只不过被发出去之后又被送回来了。到了这里，咱们能够初步怀疑是否出现了路由环路。

　　进一步在中心机房尝试tracert172.17.46.14这个IP地址跟踪路由，发现路由在中心机房交换机和地市交换机之间造成环路，数据包在环路不断往返，直到TTL值过时才被丢弃。

　　经过查看中心机房交换机路由表，发现配置了静态路由，将172.17.44.0/22这段地址指向了地市分公司交换机，而在分公司交换机配置的私网地址池里面只配置了172.17.44.0/23，并无包括172.17.46.0这段地址，因此在里面找不到对应的路由，故将流量经过默认路由又传回至中心机房，从而造成环路。检查针对其余网段的异常流量时一样出现这种状况。因此，当感染蠕虫病毒的机器与大量实际并不存在的地址创建139链接时，借助静态路由设置不当的漏洞，这些数据包在网络中循环传送，消耗了大量网络带宽，下降了网络的运行效率。 更多资料请登录中国 协议 分析网论坛[url]www.cnpaf.net[/url]查看。因此针对以上流量 分析，咱们能够得出如下结论：

⑴目前网络中存在大量中毒机器，而且正在试图经过局域网感染其余主机，最好能及时通知客户作杀毒处理，消除网络隐患。

⑵出于 安全方面的考虑，建议拒绝基于139端口的流量。

⑶中心机房交换机上须要更改静态路由，取消路由环路。
　　二，总结

　　上面的文章只是一个抛砖引玉，其实 Sniffer还有不少强大的功能，但愿你们能在平时多多使用，互相交流经验，进一步提升咱们的平常维护工做效率。

本文出自 51CTO.COM技术博客