利用sniffer做流量分析发现网络隐患.docVIP

消除网络隐患，化被动为主动 ——借助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的饼视图功能可以容易的找到流量最大的机器，如下图所示： 可以看到8，01这两台主机在目前我们网络内部流量较大，分别占16.52%和15.97％。进一步利用HostTable功能的Outline视图，可以发现这两个地址流量的90％都是HTTP流量，如下图所示： 我们可以从上图注意到，8这个主机上行流量要明显小于下行的流量，而01这个主机则是上行流量明显大于下行流量，通过确认8为一台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地