科来网络分析系统案例集
合集下载
科来网络分析系统案例集
© 2009 科来技术支持部科来软件江电话：86-2传真：86-2网址：http技术论坛：科来软件保留所部江苏办事处25-5792103325-57921033p://www.col http://www科来网应所有权利33网络分析应用案例cn析系统例统1234. 应用背景 .. 系统概述 .. 应用案例 .3.1案例分3.2网络故3.3网络故3.4网络故3.5网络故.网络故障的4.1网络故4.2网络故............................................................分析 － 某中故障诊断 － 故障诊断 － 故障诊断 － 故障诊断 － 的诊断方法 ..故障的诊断顺故障的诊断方............................................................中学网络故障查找上网速分析网络利分析网络中检测应用程....................顺序 ..............方法 ..............目 录............................................................障诊断 .........速度慢的原因利用率 .........中的流量占用程序是否正常............................................................................................................................................因 ......................................用 ..................常 ............................................................................................................................................................................................................................................................................................................................................................................................................. ‐................... ‐................... ‐................... ‐................... ‐................... ‐................... ‐. ‐ 3 ‐. ‐ 3 ‐ . ‐ 6 ‐. ‐ 6 ‐‐ 12 ‐‐ 15 ‐‐ 17 ‐‐ 20 ‐‐ 23 ‐ ‐ 23 ‐‐ 23 ‐1. 息查度快位日域网及安攻击协议时断所以攻击在这2. 它通速准非技用性分析络管应用背景目前，计算查询、邮件收快、信息价值日常工作不可网络的飞速网内部以及局安全性方面都击源等故障一议分布、通讯断时续、不能网络中的数以，随着网络击事件也必会这种大的网络系统概述科来网络分通过捕获并分准确定位故障技术人员，也性价值，并确科来网络分析，为排查网管理人员的必科来网络分分析网景算机网络的发展收发、数据共享值高、信息处理可或缺的一部速发展给企业局域网与互联都承受着巨大一直制约着网讯连接、数据包能正常上网、数据传输是不络规模的不断扩会不断增加。
精品文档-CSNA网络分析认证专家实战案例(科来软件)-第5章
先来看在6503上抓取的数据，如图5-3所示。
9
图5-3
10
在6503上捕获到10.238.230.50和10.238.103.86的会话 中，存在多个SYN包无响应的会话，从而证明确实存在订单提交不成功的问题，而在PIX的入口并没有捕获到该会话，也就 是说服务端并未收到BOSS的应用请求，所以该现象与服务器 端无关。
第5章 某移动公司BOSS系统故障分析
➢5.1 故障描述 ➢5.2 分析过程 ➢5.3 结论及建议
1
5.1 故 障 描 述
5.1.1 故障现象 (1) BOSS系统向服务器提交订单，每天会有600个左右
不成功的订单，不成功的订单需手工录入，极大地影响工作 效率，情况已持续2、3个月。
(2) 持续Ping服务器和BOSS，未出现任何丢包现象。 (3) 应用部门和应用厂商检查应用程序和规则后表示一 切正常。
13
图5-5
14
过滤FIN数据包，发现绝大部分FIN数据包都是由BOSS服 务器发出来的，见图5-6。
15
图5-6
16
再定位到TCP会话，通过“时序图”查看会话中FIN包的 情况，如图5-7所示。
17
图5-7
18
通过“时序图”可以看到，在一个会话中存在多个FIN位 置为1的数据包，而且未收到对端的确认，这表示该会话没有 正常关闭。
图5-1
5
说明： (1) BOSS系统访问10.238.103.86的80端口。 (2) BOSS系统收集营业厅的数据传给Server，BOSS既是 客户端又是服务器。 (3) 10.238.103.86将80端口映射到10.203.102.197。 (4) 将10.203.102.197 负载均衡到10.203.102.25 和 10.203.102.26。
9
图5-3
10
在6503上捕获到10.238.230.50和10.238.103.86的会话 中，存在多个SYN包无响应的会话，从而证明确实存在订单提交不成功的问题，而在PIX的入口并没有捕获到该会话，也就 是说服务端并未收到BOSS的应用请求，所以该现象与服务器 端无关。
第5章 某移动公司BOSS系统故障分析
➢5.1 故障描述 ➢5.2 分析过程 ➢5.3 结论及建议
1
5.1 故 障 描 述
5.1.1 故障现象 (1) BOSS系统向服务器提交订单，每天会有600个左右
不成功的订单，不成功的订单需手工录入，极大地影响工作 效率，情况已持续2、3个月。
(2) 持续Ping服务器和BOSS，未出现任何丢包现象。 (3) 应用部门和应用厂商检查应用程序和规则后表示一 切正常。
13
图5-5
14
过滤FIN数据包，发现绝大部分FIN数据包都是由BOSS服 务器发出来的，见图5-6。
15
图5-6
16
再定位到TCP会话，通过“时序图”查看会话中FIN包的 情况，如图5-7所示。
17
图5-7
18
通过“时序图”可以看到，在一个会话中存在多个FIN位 置为1的数据包，而且未收到对端的确认，这表示该会话没有 正常关闭。
图5-1
5
说明： (1) BOSS系统访问10.238.103.86的80端口。 (2) BOSS系统收集营业厅的数据传给Server，BOSS既是 客户端又是服务器。 (3) 10.238.103.86将80端口映射到10.203.102.197。 (4) 将10.203.102.197 负载均衡到10.203.102.25 和 10.203.102.26。
CSNA网络分析认证专家实战案例(科来软件)章 (14)
15
2．手动模式 LIMS从ERP下载数据和自动模式一样，此过程也包括2个连 接。 (1) 第1个连接调用SAP函数及模块的顺序如下： RFCPING RFC_SYSTEM_INFO RFC_SYSTEM_INFO RFC_GET_FUNCTION_INTERFACE RFC_GET_UNICODE_STRUCTURE RFC_GET_UNICODE_STRUCTURE RFC_SYSTEM_INFO
19
RFC_SYSTEM_INFO RFC_GET_UNICODE_STRUCTURE QIRF_SEND_REQUIRMENTS_GET_DATA (3) LIMS上传数据到ERP，调用SAP函数及模块的顺序如 下： RFCPING RFC_SYSTEM_INFO RFC_SYSTEM_INFO RFC_GET_FUNCTION_INTERFACE RFC_GET_UNICODE_STRUCTURE
14
RFC_GET_UNICODE_STRUCTURE RFC_SYSTEM_INFO RFC_GET_UNICODE_STRUCTURE RFC_SYSTEM_INFO RFC_GET_UNICODE_STRUCTURE RFC_SYSTEM_INFO RFC_GET_UNICODE_STRUCTURE QIRF_GET_ALL_DATA_VALUE
2
从2009年1年5日开始，ERP系统时常出现访问速度慢、业务瘫 痪甚至ERP系统死机的情况。集团网络管理人员分析后发现， 当LIMS系统断开与ERP系统的链路时，ERP系统一切正常。
继续分析后发现，在LIMS系统与ERP链路相连的时候，如 果LIMS系统使用手动模式，ERP工作正常，但使用自动模式(每 5分钟一次查询)，即会出现故障，导致ERP系统不能正常工作。 LIMS系统开发商表示，自动和手动工作模式，在工作时没有任 何区别。
2．手动模式 LIMS从ERP下载数据和自动模式一样，此过程也包括2个连 接。 (1) 第1个连接调用SAP函数及模块的顺序如下： RFCPING RFC_SYSTEM_INFO RFC_SYSTEM_INFO RFC_GET_FUNCTION_INTERFACE RFC_GET_UNICODE_STRUCTURE RFC_GET_UNICODE_STRUCTURE RFC_SYSTEM_INFO
19
RFC_SYSTEM_INFO RFC_GET_UNICODE_STRUCTURE QIRF_SEND_REQUIRMENTS_GET_DATA (3) LIMS上传数据到ERP，调用SAP函数及模块的顺序如 下： RFCPING RFC_SYSTEM_INFO RFC_SYSTEM_INFO RFC_GET_FUNCTION_INTERFACE RFC_GET_UNICODE_STRUCTURE
14
RFC_GET_UNICODE_STRUCTURE RFC_SYSTEM_INFO RFC_GET_UNICODE_STRUCTURE RFC_SYSTEM_INFO RFC_GET_UNICODE_STRUCTURE RFC_SYSTEM_INFO RFC_GET_UNICODE_STRUCTURE QIRF_GET_ALL_DATA_VALUE
2
从2009年1年5日开始，ERP系统时常出现访问速度慢、业务瘫 痪甚至ERP系统死机的情况。集团网络管理人员分析后发现， 当LIMS系统断开与ERP系统的链路时，ERP系统一切正常。
继续分析后发现，在LIMS系统与ERP链路相连的时候，如 果LIMS系统使用手动模式，ERP工作正常，但使用自动模式(每 5分钟一次查询)，即会出现故障，导致ERP系统不能正常工作。 LIMS系统开发商表示，自动和手动工作模式，在工作时没有任 何区别。
CSNA网络分析认证专家实战案例(科来软件)章 (7)
4
图7-1 5
管理员自己采取了以下方式尝试解决问题，但都没有效果： (1) 通过对广播包的检查发现部分电脑ARP包数量较多，尝 试断开发包较多的主机。 (2) 检查无法Ping通网关主机的防毒软件信息，病毒码正常， 病毒日志中未发现异常。 (3) 在无法Ping通网关的主机上安装ARP防火墙，未发现有 ARP欺骗。 (4) 管理员发现，在无法Ping通网关时，主机与局域网内的 其他电脑可以Ping通。
21
感谢22ຫໍສະໝຸດ 谢谢，精品课件资料搜集
23
从图7-3可以看到，能正常通信的主机 (MAC:00:16:35:A3:32:8B)有ARP请求数据包到达客服中心汇聚交 换机，并且也收到网关的回应数据包。
10
图7-3 11
无法正常通信的主机(MAC: 00:16:35:A3:32:11)同样也有 ARP请求数据包到达客服中心汇聚交换机，但无任何回应数据包， 如图7-4所示。
(2) 故障主机无规律性，可以排除安全设备策略方面的原因。 (3) 在主机上绑定网关MAC地址仍无法通信，可以确定网络 中无ARP欺骗病毒，问题应该出在接入交换机到网关之间。
9
7.3.1 客服中心抓包情况 在客服中心，IP为10.185.228.92(MAC:00:16:35:A3:32:8B)
的电脑可以正常通信，IP为 10.185.228.6(MAC:00:16:35:A3:32:11)的电脑无法正常通信。 对以上电脑通信进行分析。
6
7.2 分析方案设计
7.2.1 分析目标 借助网络协议分析工具，跟踪数据包走向，明确一个目标：
对比正常电脑与异常电脑通信数据包并找出异同。 7.2.2 分析设备部署
在分局办公楼及客服中心交换机上进行抓包，查看数据包走 向，如图7-2所示。
图7-1 5
管理员自己采取了以下方式尝试解决问题，但都没有效果： (1) 通过对广播包的检查发现部分电脑ARP包数量较多，尝 试断开发包较多的主机。 (2) 检查无法Ping通网关主机的防毒软件信息，病毒码正常， 病毒日志中未发现异常。 (3) 在无法Ping通网关的主机上安装ARP防火墙，未发现有 ARP欺骗。 (4) 管理员发现，在无法Ping通网关时，主机与局域网内的 其他电脑可以Ping通。
21
感谢22ຫໍສະໝຸດ 谢谢，精品课件资料搜集
23
从图7-3可以看到，能正常通信的主机 (MAC:00:16:35:A3:32:8B)有ARP请求数据包到达客服中心汇聚交 换机，并且也收到网关的回应数据包。
10
图7-3 11
无法正常通信的主机(MAC: 00:16:35:A3:32:11)同样也有 ARP请求数据包到达客服中心汇聚交换机，但无任何回应数据包， 如图7-4所示。
(2) 故障主机无规律性，可以排除安全设备策略方面的原因。 (3) 在主机上绑定网关MAC地址仍无法通信，可以确定网络 中无ARP欺骗病毒，问题应该出在接入交换机到网关之间。
9
7.3.1 客服中心抓包情况 在客服中心，IP为10.185.228.92(MAC:00:16:35:A3:32:8B)
的电脑可以正常通信，IP为 10.185.228.6(MAC:00:16:35:A3:32:11)的电脑无法正常通信。 对以上电脑通信进行分析。
6
7.2 分析方案设计
7.2.1 分析目标 借助网络协议分析工具，跟踪数据包走向，明确一个目标：
对比正常电脑与异常电脑通信数据包并找出异同。 7.2.2 分析设备部署
在分局办公楼及客服中心交换机上进行抓包，查看数据包走 向，如图7-2所示。
CSNA网络分析认证专家实战案例(科来软件)章 (1)
15
这里前置机发往网闸数据报文的目的MAC地址出现改变是否是 因为前置机的ARP表项内容变化了呢？我们在前置机的DOS窗口 下，使用“arp –a”命令查看异常时的ARP表项内容，发现网 闸IP对应的MAC地址的确变成了00:21:5E:82:AF:86。
(6) 能够导致ARP表项更新的只可能是ARP报文，是前置机 收到ARP欺骗报文导致了ARP表项的更新吗？由于前面都是针对 TCP层面的数据交互来分析的，看不到ARP报文，因此我们决定 在科来网络分析系统的“数据包”视图中查看交互过程的所有 数据报文，如图1-7所示。
22
1.4 分析结论及解决方法
通过上面的综合分析，我们可以得出结论：此次业务故障 的原因完全跟网闸无关，是由于内网的一台MAC地址为 00:21:5E:82:AF:86的设备和网闸映射的地址冲突导致的。
问题原因定位之后，我们至少可以通过以下三种方式解决 该故障：
(1) 由于是ARP表更新导致的，我们可以手动绑定网闸的 ARP，或者修改注册表，将前置机的ARP表老化时间调大。
23
(2) 找出使用了网闸映射IP的设备，修改该设备的IP地址， 或修改网上申报服务器通过网闸后映射的IP地址。
(3) 还可以让该业务系统在应用层面设置一个检测模块， 当发现有表单提交异常时，等待一段时间，重新向前置机提交 表单。
24
1.5 总 结
在刚接触到这个故障时，我们以为是网闸的原因导致的， 但是通过数据包分析后发现是由于网络中IP地址冲突导致的。 所以在接触到故障时，不要主观地臆测故障原因，而是要通过 分析的手段找到根本的原因，以便提高故障解决的效率。
(1) 网上申报业务系统运行时，每天总有一部分纳税人的 申报表单数据无法正常上传，通过征管服务器的业务软件可以 看到这些用户的申报数据处于锁死状态。
这里前置机发往网闸数据报文的目的MAC地址出现改变是否是 因为前置机的ARP表项内容变化了呢？我们在前置机的DOS窗口 下，使用“arp –a”命令查看异常时的ARP表项内容，发现网 闸IP对应的MAC地址的确变成了00:21:5E:82:AF:86。
(6) 能够导致ARP表项更新的只可能是ARP报文，是前置机 收到ARP欺骗报文导致了ARP表项的更新吗？由于前面都是针对 TCP层面的数据交互来分析的，看不到ARP报文，因此我们决定 在科来网络分析系统的“数据包”视图中查看交互过程的所有 数据报文，如图1-7所示。
22
1.4 分析结论及解决方法
通过上面的综合分析，我们可以得出结论：此次业务故障 的原因完全跟网闸无关，是由于内网的一台MAC地址为 00:21:5E:82:AF:86的设备和网闸映射的地址冲突导致的。
问题原因定位之后，我们至少可以通过以下三种方式解决 该故障：
(1) 由于是ARP表更新导致的，我们可以手动绑定网闸的 ARP，或者修改注册表，将前置机的ARP表老化时间调大。
23
(2) 找出使用了网闸映射IP的设备，修改该设备的IP地址， 或修改网上申报服务器通过网闸后映射的IP地址。
(3) 还可以让该业务系统在应用层面设置一个检测模块， 当发现有表单提交异常时，等待一段时间，重新向前置机提交 表单。
24
1.5 总 结
在刚接触到这个故障时，我们以为是网闸的原因导致的， 但是通过数据包分析后发现是由于网络中IP地址冲突导致的。 所以在接触到故障时，不要主观地臆测故障原因，而是要通过 分析的手段找到根本的原因，以便提高故障解决的效率。
(1) 网上申报业务系统运行时，每天总有一部分纳税人的 申报表单数据无法正常上传，通过征管服务器的业务软件可以 看到这些用户的申报数据处于锁死状态。
基于科来网络分析技术的ARP欺骗分析案例
基于科来网络分析技术的ARP欺骗分析案例在局域网中，IP地址转换为第二层物理地址(即MAC地址)是通过ARP协议来完成的，ARP协议对网络安全具有极其重要的意义。
主机通过伪造IP地址和MAC地址实现ARP欺骗，能够在网络中产生大量的ARP通信量使网络阻塞。
本文通过一次经典的分析案例，让大家对这种攻击方式有一个清晰的了解。
案例背景办公机的网段是192.168.200.X/24的，办公机的网关地址是192.168.200.254在Cisco 3560上，服务器的地址段为10.139.144.X/24。
在办公区访问服务器区时，会出现时通时断的现象。
办公机是通过DHCP来获取IP地址，当访问出现不通时，重新获取一下IP地址，就可以连通，但是用一会又会出现访问中断的情况。
该局的网络环境比较简单，如下图所示：案例分析出现故障时，通过Ping服务器地址发现无法Ping通，然后通过Ping办公机的网关地址，发现网关地址也无法Ping通。
查看办公机的ARP表发现网关地址对应的MAC地址为全0的MAC地址。
通过上面的分析测试我们可以了解到，当主机无法访问服务器时，主机连网关都无法Ping通，而且主机中网关的MAC地址全0，即主机没有学习到网关的MAC地址，所以主机无法跟网关进行通信，从而导致主机无法连通服务器。
正常连接时主机应该有网关的IP地址和MAC地址的ARP映射表的，但是在访问服务器不成功时并没有学习到网关的MAC地址，造成这种故障的原因很大可能性是网络中ARP欺骗。
为了验证网络是否有ARP欺骗，我们在交换机3560上做端口镜像来抓取交互的数据包。
办公机连到3560的端口是f 0/46，所以我们只镜像f 0/46，将该端口镜像到端口f 0/25，然后把科来网络分析系统接到f 0/25端口上捕获通信的数据包。
数据包分析我们在分析数据包时发现，网络中存在大量的IP冲突。
通过诊断视图中的诊断提示，发现产生IP地址冲突的源IP地址是故障网段的网关地址，如下图所示：通过观察上图，我们可以发现192.168.200.254对应的MAC地址有两个，一个是00:25:64:A8:74:AD，一个是00:1A:A2:87:d1:5A，通过具体的分析我们发现MAC地址为00:25:64:A8:74:AD的主机对应的IP地址为192.168.200.33， 00:1A:A2:87:d1:5A才是192.168.200.254真实的MAC地址。
CSNA网络分析认证专家实战案例(科来软件)章 (29)
以上信息证明，该网络的确存在问题，需要进一步分析原因。
5
29.1.2 网络与应用结构 在进行分析前，通过与技术负责人简单的交流，得知其网络
大致结构如图29-2所示。
6
图29-2 7
上面的拓扑结构简明地描述了用户的网络和应用部署结构， 需要说明的有
(1) IPS没有过多的策略定制。 (2) FW对所有流量均透明。 (3) 流控设备仅对内部用户启用NAT，外网用户访问DMZ或 DMZ流向外网数据均未配置NAT。 (4) 用户拥有103.16.80.0/129的公网IP地址，除了路由器 和流控设备使用了2个外，其他的都用在DMZ区域。
9
用户A在内网的访问IP地址变化如下： (1) 发送数据包：A: IP——>B:103.16.80.131—— >E:103.16.80.189。 (2) 返回数据包：E:103.16.80.189—— >B:103.16.80.131——> A: IP。 其中，用户A的IP为私有IP地址(内网用户均使用私有IP)。
12
29.2.2 分析设备部署 如图29-4所示，将科来网络分析系统接入到交换机D的流量
镜像端口。由于未知丢包原因或目标(几乎所有DMZ主机都丢包)， 建议不设置任何过滤器，即捕获所有数据包。
13
29.2.3 分析档案与方案选择 在使用科来网络分析系统前，选择正确的分析档案和分析方
案对分析效率及数据处理性能都有极大的优化作用，这一步不可 忽视。根据用户的实际网络情况以及对应的问题特性，在进行数 据捕获时采用如图29-5所示的网络档案和分析方案，且不进行任 何过滤器设置。
2
从业务操作层面来讲，无论是内部用户还是外部用户，在访 问其Web或其他服务器时，感觉较慢；从技术层面做简单的Ping 测试，出现如图29-1所示的现象。
5
29.1.2 网络与应用结构 在进行分析前，通过与技术负责人简单的交流，得知其网络
大致结构如图29-2所示。
6
图29-2 7
上面的拓扑结构简明地描述了用户的网络和应用部署结构， 需要说明的有
(1) IPS没有过多的策略定制。 (2) FW对所有流量均透明。 (3) 流控设备仅对内部用户启用NAT，外网用户访问DMZ或 DMZ流向外网数据均未配置NAT。 (4) 用户拥有103.16.80.0/129的公网IP地址，除了路由器 和流控设备使用了2个外，其他的都用在DMZ区域。
9
用户A在内网的访问IP地址变化如下： (1) 发送数据包：A: IP——>B:103.16.80.131—— >E:103.16.80.189。 (2) 返回数据包：E:103.16.80.189—— >B:103.16.80.131——> A: IP。 其中，用户A的IP为私有IP地址(内网用户均使用私有IP)。
12
29.2.2 分析设备部署 如图29-4所示，将科来网络分析系统接入到交换机D的流量
镜像端口。由于未知丢包原因或目标(几乎所有DMZ主机都丢包)， 建议不设置任何过滤器，即捕获所有数据包。
13
29.2.3 分析档案与方案选择 在使用科来网络分析系统前，选择正确的分析档案和分析方
案对分析效率及数据处理性能都有极大的优化作用，这一步不可 忽视。根据用户的实际网络情况以及对应的问题特性，在进行数 据捕获时采用如图29-5所示的网络档案和分析方案，且不进行任 何过滤器设置。
2
从业务操作层面来讲，无论是内部用户还是外部用户，在访 问其Web或其他服务器时，感觉较慢；从技术层面做简单的Ping 测试，出现如图29-1所示的现象。
科来网络分析系统2篇
科来网络分析系统2篇篇一：科来网络分析系统介绍科来网络分析系统是一款专门针对网络安全领域的软件，能够帮助用户进行实时网络流量的检测，发现和诊断网络攻击以及异常行为。
该系统是建立在深度学习、机器学习、以及数据挖掘等技术基础上，具有较高的可靠性和准确度。
科来网络分析系统的核心技术在于其能够抽取网络数据包的协议字段，从而实现对数据包的分类，进而检测出网络攻击行为。
在此基础上，系统采用了多种算法模型，如决策树算法、贝叶斯算法、深度学习算法等，提高了系统的检测准确率和性能。
同时，系统还能够进行流量分析，实现实时的网络流量监测，发现对网络安全造成潜在威胁的攻击事件。
此外，该系统还能够生成详细的报告，帮助用户了解整个网络环境中的漏洞和风险，并提供具体的解决方案。
科来网络分析系统可以适用于各种复杂的网络环境，包括企业、机构、及政府等不同的网络场景。
该系统已经被广泛应用于网络安全评估、入侵检测、流量分析、以及网络威胁情报等领域。
科来网络分析系统的优点主要在于以下几个方面：一、高性能。
科来网络分析系统具备较高的吞吐量和低延迟，能够实现实时的网络流量监测，并对网络攻击行为进行快速检测与回应。
二、高可靠性。
科来网络分析系统使用了多种算法模型，能够有效地降低误报率和漏报率，提高系统的可靠性和安全性。
三、易于操作和管理。
科来网络分析系统提供了友好的用户界面，让用户可以轻松地完成系统的配置、管理和监控。
综上所述，科来网络分析系统是一款安全性高、性能卓越的网络安全分析软件，能够有效发现和识别网络攻击行为，为用户提供实时的威胁情报和报告，帮助用户快速、准确地应对网络安全威胁。
篇二：科来网络分析系统的应用案例分析科来网络分析系统在网络安全评估、入侵检测、流量分析、以及网络威胁情报等领域具有广泛的应用。
下面结合具体案例，介绍该系统在实际应用中的表现和效果。
应用案例一：企业网络安全评估某企业针对其网络安全状态进行了评估，使用了科来网络分析系统进行了网络流量监测和分析。
CSNA网络分析认证专家实战案例(科来软件)章 (39)
接下来查看“IP端点”流量情况，如图39-16所示。
31
图39-15 32
图39-16 33
通过“IP端点”视图我们发现，10.140.107.204这个地址是 他们内网服务器的地址，为何TCP的同步发送与同步确认比例这 么大呢(64.39、63.53、63.5等地址不用看，因为都是中了蠕虫 的缘故)？马上进行定位分析，查看“TCP会话”，如图39-17所 示。
第39章 某供电局内部网络分析
➢39.1 故障描述 ➢39.2 故障分析 ➢39.3 总结213
1
39.1 故 障 描 述
某供电局网络负责人向我们求助，说供电局下面的乡镇访问 网络中服务器时时断时续，Ping核心层设备也有延迟和丢包，同 时他们网络中的其他网段访问服务器也出现此类情况。这种情况 已持续数天，使用许多办法还是没找到发生问题的故障点。由于 客户急于交电费，该负责人直接将捕获的数据包传给我们，让我 们马上分析。
接尝试，见图39-11。根据以往的分析经验，我们猜想可能是蠕 虫在进行TCP泛洪扫描。为了进一步验证我们的判断，查看“IP 会话”，如图39-12所示。
24
图39-11 25
图39-12 26
从图中可以看到，172.169.63.53这个地址只发送而不接收 数据包，同时网络是内网，但是该地址在扫描外网地址。再查看 “TCP会话”，如图39-13所示。
17
39.2.4 对网络层进行分析 从图39-8中可以看到，IP TTL太小，可以立刻判断出网络中
存在路由环路。为了进一步确认这一点，查看具体数据包，如图 39-9所示。
18
图39-8 19
图39-9 20
从图39-9中可以看到TTL值一直递减到0，可以确认网络中出 现了路由环路。与网管沟通后得知192.168.1.0网段不存在，但 是经核实确实存在路由环路。于是我们写了一条ACL(Access Control List，访问控制列表)，使192.168.1.0网段指向 “null0”(伪接口，不能分配地址，这样就可以有效防止路由环 路问题)。
31
图39-15 32
图39-16 33
通过“IP端点”视图我们发现，10.140.107.204这个地址是 他们内网服务器的地址，为何TCP的同步发送与同步确认比例这 么大呢(64.39、63.53、63.5等地址不用看，因为都是中了蠕虫 的缘故)？马上进行定位分析，查看“TCP会话”，如图39-17所 示。
第39章 某供电局内部网络分析
➢39.1 故障描述 ➢39.2 故障分析 ➢39.3 总结213
1
39.1 故 障 描 述
某供电局网络负责人向我们求助，说供电局下面的乡镇访问 网络中服务器时时断时续，Ping核心层设备也有延迟和丢包，同 时他们网络中的其他网段访问服务器也出现此类情况。这种情况 已持续数天，使用许多办法还是没找到发生问题的故障点。由于 客户急于交电费，该负责人直接将捕获的数据包传给我们，让我 们马上分析。
接尝试，见图39-11。根据以往的分析经验，我们猜想可能是蠕 虫在进行TCP泛洪扫描。为了进一步验证我们的判断，查看“IP 会话”，如图39-12所示。
24
图39-11 25
图39-12 26
从图中可以看到，172.169.63.53这个地址只发送而不接收 数据包，同时网络是内网，但是该地址在扫描外网地址。再查看 “TCP会话”，如图39-13所示。
17
39.2.4 对网络层进行分析 从图39-8中可以看到，IP TTL太小，可以立刻判断出网络中
存在路由环路。为了进一步确认这一点，查看具体数据包，如图 39-9所示。
18
图39-8 19
图39-9 20
从图39-9中可以看到TTL值一直递减到0，可以确认网络中出 现了路由环路。与网管沟通后得知192.168.1.0网段不存在，但 是经核实确实存在路由环路。于是我们写了一条ACL(Access Control List，访问控制列表)，使192.168.1.0网段指向 “null0”(伪接口，不能分配地址，这样就可以有效防止路由环 路问题)。
精品文档-CSNA网络分析认证专家实战案例(科来软件)-第30章
18
图30-7
19
至此我们可以确定，TCP峰值的产生是由于202.108.212.50 和202.108.212.28这两个IP的主机对网站进行扫描所致。这种扫 描对网站产生一些威胁，而且也对服务器造成很大压力，影响其 他用户的正常访问。
20
30.3 结 论
从这两个案例我们看到回溯式分析对网络安全的重要意义： 通过对异常流量的分析，快速定位引起异常流量的原因，了解网 络中存在的攻击现象，使网管人员制定防止措施并加固网络有了 明确的指导方向。
15
我们下载这段数据包，首先看其“TCP会话”，发现外网IP 202.108.212.50和202.108.212.28在对该单位网站IP 218.247.187.68进行高频率的访问，其频率之高绝对不是人工点 击网站所能形成，在1秒时间内会话请求就达到300多个。
16
图30-6
17
这种会话具有明显的扫描特征，我们查看HTTP日志，发现 202.108.212.50对该单位网站的请求有明显按照目录逐级访问的 特征，如图30-7所示。
3
在一次例行的检查中，我们从流量趋势图中发现该单位在凌 晨5时左右有一个流量突起，而这个时段应该没有什么业务流量， 如图30-1所示。
4
图30-1
5
我们看到，突起发生的时间段位于6月30日5时24分到6时12 分之间。选中该段时间进行分析，从IP地址栏可以看到，地址为 60.30.29.10的IP流量达到528 MB，远远超过其他IP，应该是引 起此处流量突起的原因。对60.30.29.10进行挖掘分析发现，该 IP的大多数TCP会话都是与218.247.187.68通信产生的，而IP 218.247.187.68是该网络的服务器IP。
图30-7
19
至此我们可以确定，TCP峰值的产生是由于202.108.212.50 和202.108.212.28这两个IP的主机对网站进行扫描所致。这种扫 描对网站产生一些威胁，而且也对服务器造成很大压力，影响其 他用户的正常访问。
20
30.3 结 论
从这两个案例我们看到回溯式分析对网络安全的重要意义： 通过对异常流量的分析，快速定位引起异常流量的原因，了解网 络中存在的攻击现象，使网管人员制定防止措施并加固网络有了 明确的指导方向。
15
我们下载这段数据包，首先看其“TCP会话”，发现外网IP 202.108.212.50和202.108.212.28在对该单位网站IP 218.247.187.68进行高频率的访问，其频率之高绝对不是人工点 击网站所能形成，在1秒时间内会话请求就达到300多个。
16
图30-6
17
这种会话具有明显的扫描特征，我们查看HTTP日志，发现 202.108.212.50对该单位网站的请求有明显按照目录逐级访问的 特征，如图30-7所示。
3
在一次例行的检查中，我们从流量趋势图中发现该单位在凌 晨5时左右有一个流量突起，而这个时段应该没有什么业务流量， 如图30-1所示。
4
图30-1
5
我们看到，突起发生的时间段位于6月30日5时24分到6时12 分之间。选中该段时间进行分析，从IP地址栏可以看到，地址为 60.30.29.10的IP流量达到528 MB，远远超过其他IP，应该是引 起此处流量突起的原因。对60.30.29.10进行挖掘分析发现，该 IP的大多数TCP会话都是与218.247.187.68通信产生的，而IP 218.247.187.68是该网络的服务器IP。
CSNA网络分析认证专家实战案例(科来软件)章 (24)
4
图24-1 5
客户想了解自己网管网络的IP节点的情况，希望能将 100.0这个网段能独立地监控。在IP节点里面添加这个网段即 可，如图24-2所示。
6
图24-2 7
24.2 分 析 过 程
在抓包过程中我们也进行分析，设置网络利用率后，发现 网络始终处于利用率100% 的状态，如图24-3所示。
18
图24-8 19
这种大量的80端口被BT占用所产生的数据，造成80端口流 量占总流量的80%以上。此种80传输是防火墙默认放行的，其 连接数也不多，恰好能够绕过防火墙的设置进行下载，而且现 在大多数的BT协议都支持这种借用80端口进行传输，如迅雷， 通过简单的设置就可以实现，如图24-9所示。
20
图24-9 21
另外，在本次网络检查中我们也发现了蠕虫情况。对内网 IP的TCP会话进行排名，我们发现IP 192.168.2.67流量较小， 只有122 KB，但其TCP会话排名第二位(第一位是其内部服务 器)。我们对此IP进行定位分析，看其TCP会话发现具有蠕虫特 征，如图24-10所示。
第24章 BT流量通过TCP 80 端口占用和蠕虫攻击
➢24.1 故障描述 ➢24.2 分析过程 ➢24.3 分析总结
1
24.1 故 障 描 述
最近一些客户反映他们网络响应很慢，邮件有时也无法正 常收发，想了解是什么原因造成的。
2
一开始，客户把自己的子网100.0这个网段的VLAN流量做 了镜像，想分析为什么这么慢。我们看了下抓取的数据，发现 100.0这个网段的数据是正常的，只是比较慢。然后我们询问 客户是否只是100.0这个网段慢，客户说是整个网络都很慢。 如果整个网络都慢，那只在一个网段抓包，取得的数据是不全 面的。于是我们建议客户将该镜像改为镜像网络总出口的流量。
图24-1 5
客户想了解自己网管网络的IP节点的情况，希望能将 100.0这个网段能独立地监控。在IP节点里面添加这个网段即 可，如图24-2所示。
6
图24-2 7
24.2 分 析 过 程
在抓包过程中我们也进行分析，设置网络利用率后，发现 网络始终处于利用率100% 的状态，如图24-3所示。
18
图24-8 19
这种大量的80端口被BT占用所产生的数据，造成80端口流 量占总流量的80%以上。此种80传输是防火墙默认放行的，其 连接数也不多，恰好能够绕过防火墙的设置进行下载，而且现 在大多数的BT协议都支持这种借用80端口进行传输，如迅雷， 通过简单的设置就可以实现，如图24-9所示。
20
图24-9 21
另外，在本次网络检查中我们也发现了蠕虫情况。对内网 IP的TCP会话进行排名，我们发现IP 192.168.2.67流量较小， 只有122 KB，但其TCP会话排名第二位(第一位是其内部服务 器)。我们对此IP进行定位分析，看其TCP会话发现具有蠕虫特 征，如图24-10所示。
第24章 BT流量通过TCP 80 端口占用和蠕虫攻击
➢24.1 故障描述 ➢24.2 分析过程 ➢24.3 分析总结
1
24.1 故 障 描 述
最近一些客户反映他们网络响应很慢，邮件有时也无法正 常收发，想了解是什么原因造成的。
2
一开始，客户把自己的子网100.0这个网段的VLAN流量做 了镜像，想分析为什么这么慢。我们看了下抓取的数据，发现 100.0这个网段的数据是正常的，只是比较慢。然后我们询问 客户是否只是100.0这个网段慢，客户说是整个网络都很慢。 如果整个网络都慢，那只在一个网段抓包，取得的数据是不全 面的。于是我们建议客户将该镜像改为镜像网络总出口的流量。
CSNA网络分析认证专家实战案例(科来软件)章 (26)
12
图26-4 13
从图中可以发现的异常结果如下： (1) TCP流异常。 TCP同步发送数量为2 771 211，而同步确认发送数量为 2090个，同步发送数量远高于同步确认数量，明显为异常现 象，需进一步分析。 (2) HTTP应用异常。 HTTP连接数量为97 121，HTTP请求数量为440，也就是 说绝大多数的HTTP连接中没有任何HTTP请求，明显异常。
5
26.2.2 分析设备部署 我们在交换机上部署分析设备，镜像出口的网络流量，
对出口的流量进行捕Байду номын сангаас并分析。
6
26.3 分 析 情 况
26.3.1 基本流量分析 首先，利用科来网络分析系统的实时网络流量监控分析
功能，对网络中的重要流量参数进行监控分析，确认是否由 于网络拥塞导致服务器无法访问，并确认有无异常流量。总 体流量监控视图如图26-2所示。
20
感谢
21
谢谢，精品课件
资料搜集
22
第26章 Web服务器攻击分析
26.1 故障描述 26.2 分析方案设计 26.3 分析情况 26.4 分析结论
1
26.1 故 障 描 述
26.1.1 故障现象 客户对外服务的Web服务器无法访问，内网机器访问互
联网速度较慢。
2
26.1.2 基本环境 用户的Internet出口基本网络拓扑如图26-1所示，其中
14
分析结论：TCP同步发送和同步确认数量明显异常， HTTP连接数量远远大于HTTP请求数量，这些异常很可能是由 于攻击造成的。
15
26.3.3 针对Web服务器访问流量进行分析 利用科来网络分析系统的端点分析视图和节点浏览器，
针对性地对Web服务器主机流量进行分析，确认其没有响应 的原因。
图26-4 13
从图中可以发现的异常结果如下： (1) TCP流异常。 TCP同步发送数量为2 771 211，而同步确认发送数量为 2090个，同步发送数量远高于同步确认数量，明显为异常现 象，需进一步分析。 (2) HTTP应用异常。 HTTP连接数量为97 121，HTTP请求数量为440，也就是 说绝大多数的HTTP连接中没有任何HTTP请求，明显异常。
5
26.2.2 分析设备部署 我们在交换机上部署分析设备，镜像出口的网络流量，
对出口的流量进行捕Байду номын сангаас并分析。
6
26.3 分 析 情 况
26.3.1 基本流量分析 首先，利用科来网络分析系统的实时网络流量监控分析
功能，对网络中的重要流量参数进行监控分析，确认是否由 于网络拥塞导致服务器无法访问，并确认有无异常流量。总 体流量监控视图如图26-2所示。
20
感谢
21
谢谢，精品课件
资料搜集
22
第26章 Web服务器攻击分析
26.1 故障描述 26.2 分析方案设计 26.3 分析情况 26.4 分析结论
1
26.1 故 障 描 述
26.1.1 故障现象 客户对外服务的Web服务器无法访问，内网机器访问互
联网速度较慢。
2
26.1.2 基本环境 用户的Internet出口基本网络拓扑如图26-1所示，其中
14
分析结论：TCP同步发送和同步确认数量明显异常， HTTP连接数量远远大于HTTP请求数量，这些异常很可能是由 于攻击造成的。
15
26.3.3 针对Web服务器访问流量进行分析 利用科来网络分析系统的端点分析视图和节点浏览器，
针对性地对Web服务器主机流量进行分析，确认其没有响应 的原因。
精品文档-CSNA网络分析认证专家实战案例(科来软件)-第32章
13
32.2.3 有效数据传输分析 在该TCP连接建立了0.66秒的时候(见图32-4)，服务器已经
给出了“FIN”——结束连接的信号，这是否意味着该时刻服务 器已经传完数据了？
14
图32-4
15
对客户端收到“ACK,FIN”包之后的数据包解码分析可以看 到，之后的数据包内容都是“Connection：keep-alive”——保 持连接不中断(见图32-5)，以及刷新客户端服务器状态。
直接在客户端上安装科来网络分析系统2010，打开科来网络 分析系统2010并开始捕获数据包；然后打开行情查询软件客户端， 从在软件上点击“查询数据”时开始计时，到行情信息出现，总 共用了5秒钟。
4
32.2.1 TCP交互延时分析原理 对于业务系统“慢”的现象，我们可以通过科来网络分析系
统延时分析的技巧去定位问题。三次握手分析网络延时的过程如 图32-1所示。
16
图32-5
17
综上所述，我们可以确认：在0.66秒的时候，客户端已经收 到服务器所有的数据，客户端软件将在应用层处理这些数据，并 将行情的数据显示出来，而客户端应用层在处理数据的时候明显 耗时过长，5秒后我们才在客户端软件上看到行情信息。
由此可见，这次故障的原因主要在客户端处理数据这一过程。 之后，我们尝试了几次访问，获得如表32-1所示的统计表格。
第32章 某金融机构行情查询系统分析案例
➢32.1 ➢32.2 ➢32.3
故障描述 分析过程 问题解决
1
32.1 故 障 描 述
某金融机构的IDC机房新使用一套行情查询系统，为各个营 业网点提供行情信息查询服务。该业务系统上线后，不少营业网 点均反映说该系很慢，具体表现在客户端打开行情软件并点击 查询之后，往往要好几秒钟甚至更长时间才会出现行情信息。
32.2.3 有效数据传输分析 在该TCP连接建立了0.66秒的时候(见图32-4)，服务器已经
给出了“FIN”——结束连接的信号，这是否意味着该时刻服务 器已经传完数据了？
14
图32-4
15
对客户端收到“ACK,FIN”包之后的数据包解码分析可以看 到，之后的数据包内容都是“Connection：keep-alive”——保 持连接不中断(见图32-5)，以及刷新客户端服务器状态。
直接在客户端上安装科来网络分析系统2010，打开科来网络 分析系统2010并开始捕获数据包；然后打开行情查询软件客户端， 从在软件上点击“查询数据”时开始计时，到行情信息出现，总 共用了5秒钟。
4
32.2.1 TCP交互延时分析原理 对于业务系统“慢”的现象，我们可以通过科来网络分析系
统延时分析的技巧去定位问题。三次握手分析网络延时的过程如 图32-1所示。
16
图32-5
17
综上所述，我们可以确认：在0.66秒的时候，客户端已经收 到服务器所有的数据，客户端软件将在应用层处理这些数据，并 将行情的数据显示出来，而客户端应用层在处理数据的时候明显 耗时过长，5秒后我们才在客户端软件上看到行情信息。
由此可见，这次故障的原因主要在客户端处理数据这一过程。 之后，我们尝试了几次访问，获得如表32-1所示的统计表格。
第32章 某金融机构行情查询系统分析案例
➢32.1 ➢32.2 ➢32.3
故障描述 分析过程 问题解决
1
32.1 故 障 描 述
某金融机构的IDC机房新使用一套行情查询系统，为各个营 业网点提供行情信息查询服务。该业务系统上线后，不少营业网 点均反映说该系很慢，具体表现在客户端打开行情软件并点击 查询之后，往往要好几秒钟甚至更长时间才会出现行情信息。
CSNA网络分析认证专家实战案例(科来软件)章 (6)
而控制进程在空闲的34分钟内没有采用长连接机制保持连接， 所以被防火墙中断了，再有电话接入的时候便会出现接听失败 的现象。
18
6.3 解决问题建议
(1) 修改防火墙的策略：增长访问北京10.10.203.155的 TCP连接的空闲时间。该策略实施后，偶发故障出现的次数明显 下降。
(2) 优化客服控制插件程序设置，从根本上解决问题。
14
图6-5 15
果然，客户端在空闲2090秒(34分钟)的时间内没有发送任 何保持连接的数据包，等到客服电脑重新发起接听电话请求的 时候，客户端的请求已经无法到达服务器端，一直在发起重传 的请求，最后客服人员看到请求超时的告警提示，如图6-6所示。
16
图6-6 17
6.2.6 故障原因分析 大部分防火墙都会将空闲时间超过30分钟的TCP连接断开，
信流量，如图6-2所示。这两台服务器的IP分别是 10.10.176.51(经确认为客服软件界面的服务器)和 10.10.203.155(经确认是客服软件控制插件的服务器)。
8
图6-2 9
6.2.4 软件界面连接分析 从客服电脑10.10.22.21与服务器10.10.176.51通信的TCP
时序图可以看到，两者采用了长连接的机制，在空闲的时间段， 客户端每隔几秒钟就会发送一个GET的请求以与服务器保持连接， 如图6-3所示。
10
图6-3 11
从16时12分至16时48分，每隔6分钟客户端与服务器就更新 一次TCP连接，未曾中断过，因此软件界面一直能够正常显示， 见图6-4。
12
图6-4 13
6.2.5 控制插件连接分析 客服电脑10.10.22.21与服务器10.10.203.155在16时12分
至16时48分这段时间只有3对TCP连接一直保持，如图6-5所示。 如果这3对TCP连接没有采用长连接的传输机制，很可能会因为 空闲太长时间而被网络中的防火墙等设备中断连接。
18
6.3 解决问题建议
(1) 修改防火墙的策略：增长访问北京10.10.203.155的 TCP连接的空闲时间。该策略实施后，偶发故障出现的次数明显 下降。
(2) 优化客服控制插件程序设置，从根本上解决问题。
14
图6-5 15
果然，客户端在空闲2090秒(34分钟)的时间内没有发送任 何保持连接的数据包，等到客服电脑重新发起接听电话请求的 时候，客户端的请求已经无法到达服务器端，一直在发起重传 的请求，最后客服人员看到请求超时的告警提示，如图6-6所示。
16
图6-6 17
6.2.6 故障原因分析 大部分防火墙都会将空闲时间超过30分钟的TCP连接断开，
信流量，如图6-2所示。这两台服务器的IP分别是 10.10.176.51(经确认为客服软件界面的服务器)和 10.10.203.155(经确认是客服软件控制插件的服务器)。
8
图6-2 9
6.2.4 软件界面连接分析 从客服电脑10.10.22.21与服务器10.10.176.51通信的TCP
时序图可以看到，两者采用了长连接的机制，在空闲的时间段， 客户端每隔几秒钟就会发送一个GET的请求以与服务器保持连接， 如图6-3所示。
10
图6-3 11
从16时12分至16时48分，每隔6分钟客户端与服务器就更新 一次TCP连接，未曾中断过，因此软件界面一直能够正常显示， 见图6-4。
12
图6-4 13
6.2.5 控制插件连接分析 客服电脑10.10.22.21与服务器10.10.203.155在16时12分
至16时48分这段时间只有3对TCP连接一直保持，如图6-5所示。 如果这3对TCP连接没有采用长连接的传输机制，很可能会因为 空闲太长时间而被网络中的防火墙等设备中断连接。
CSNA网络分析认证专家实战案例(科来软件)章 (19)
通过在交换机上旁路部署回溯分析系统，连续采集几日的流 量数据，对出现问题的时段进行重点分析。在如图19-2所示的某 出现断网时段出口链路的流量概要统计我们可以看出，流量没有 明显异常，但是TCP同步包发送偏多，和同步确认接收比例在 1∶2左右。
4
图19-2 5
从如图19-3所示的网络应用流量排名表中可以看出，网络应 用以HTTP和未知UDP应用居多，算是正常现象。同时查看IP会话 和TCP会话也没有发现明显的异常。
6
图19-3 7
下载完整数据包并通过专家系统进行分析，智能诊断结果见 图19-4。
8
图19-4 9
在和代理商工程师排除了ARP问题和网络层问题以后我们感 觉还是一头雾水，但是在IP端点查看发现了大量的以192.168开 头的IP，如图19-5所示。
10
图19-5 11
用户网络中只有192.168.0.0/24到192.168.3.0/24四段C类 地址，上图中大部分地址并不是客户内网的地址。同时发现这些 地址的数据包很有规律，大小都是164 B，都是发两个包。定位 到这些异常IP地址，发现这些IP的应用都是CIFS，而且都是收到 两个SYN包，见图19-6。
25
之后，用户对上述两台机器进行了彻底杀毒，并更新到最新 的操作系统补丁，就再没有断网的现象发生了。
26
感谢
27
谢谢，精品课件
资料搜集
28
21
图19-11 22
这些域名的二级名称看起来是一些无序的字母组合，很多恶 意程序都会利用算法计算出的域名反弹上线。通过谷歌搜索这些 域名，发现这些域名有的可以看到安全威胁记录，而有些查询不 到任何信息，如图19-12所示。
23
图19-12 24
4
图19-2 5
从如图19-3所示的网络应用流量排名表中可以看出，网络应 用以HTTP和未知UDP应用居多，算是正常现象。同时查看IP会话 和TCP会话也没有发现明显的异常。
6
图19-3 7
下载完整数据包并通过专家系统进行分析，智能诊断结果见 图19-4。
8
图19-4 9
在和代理商工程师排除了ARP问题和网络层问题以后我们感 觉还是一头雾水，但是在IP端点查看发现了大量的以192.168开 头的IP，如图19-5所示。
10
图19-5 11
用户网络中只有192.168.0.0/24到192.168.3.0/24四段C类 地址，上图中大部分地址并不是客户内网的地址。同时发现这些 地址的数据包很有规律，大小都是164 B，都是发两个包。定位 到这些异常IP地址，发现这些IP的应用都是CIFS，而且都是收到 两个SYN包，见图19-6。
25
之后，用户对上述两台机器进行了彻底杀毒，并更新到最新 的操作系统补丁，就再没有断网的现象发生了。
26
感谢
27
谢谢，精品课件
资料搜集
28
21
图19-11 22
这些域名的二级名称看起来是一些无序的字母组合，很多恶 意程序都会利用算法计算出的域名反弹上线。通过谷歌搜索这些 域名，发现这些域名有的可以看到安全威胁记录，而有些查询不 到任何信息，如图19-12所示。
23
图19-12 24
CSNA网络分析认证专家实战案例(科来软件)章 (37)
8
图37-2 9
2．TCP连接会话趋势分析 如图37-3和图37-4所示，在测试期间，客户端发起的连接请 求数为824次，TCP连接会话峰值为37次/秒，出现小规律性的突 发。由于TCP会话数量较少，说明网络中不存在 DDoS(Distributed Denial of Service，分布式拒绝服务)攻击 或TCP扫描现象。服务器“同步确认”响应了577次，“结束连接” 会话为757次，数量变化趋势基本相同，这说明网络性能良好， 对大部分连接请求都能快速响应。 以上网络各项统计指标分析显示，网络运行属于正常状态， 无网
6
37.2 故 障 分 析
37.2.1 网络承载性能分析 1．流量统计趋势分析 如图37-2所示，利用率等于在测试期间当前网络使用的每秒
速率除以1000 Mbps以太网速率，可以证明当前校园网络使用每 秒位速率已达到12.431 Mbps。
7
在网络测试期间，从流量趋势图来看，流量峰值为1.877 MB， 网络中并未出现规律性的大流量突发现象；从数据包大小分布情 况来看，网络中产生的1024～1517 B的大包占用较多，为46.817 MB，说明网络存在大数据量的传输。
(3) 由于学校在放假期间校园网用户相对较少，在测试期间 客户端发起的连接请求数为824次，TCP连接会话峰值为37次/秒， 出现小规律性的突发。由于TCP会话数量较少，说明网络中不存 在DDoS攻击或TCP扫描现象。假如在开学期间学生用户上网较多 或受到黑客DDoS攻击，如不采取应急措施，网络会话连接数过多， 网关设备处理转发响应数据时CPU高负荷，导致网络瘫痪。
37.2.2 Top应用层协议分析 通过图37-6可以直观地得出网络中应用的情况，主要使用
UDP-Other、HTTP、TCP-Other等应用协议，可以进一步分析哪些 主机地址使用了这些应用。
图37-2 9
2．TCP连接会话趋势分析 如图37-3和图37-4所示，在测试期间，客户端发起的连接请 求数为824次，TCP连接会话峰值为37次/秒，出现小规律性的突 发。由于TCP会话数量较少，说明网络中不存在 DDoS(Distributed Denial of Service，分布式拒绝服务)攻击 或TCP扫描现象。服务器“同步确认”响应了577次，“结束连接” 会话为757次，数量变化趋势基本相同，这说明网络性能良好， 对大部分连接请求都能快速响应。 以上网络各项统计指标分析显示，网络运行属于正常状态， 无网
6
37.2 故 障 分 析
37.2.1 网络承载性能分析 1．流量统计趋势分析 如图37-2所示，利用率等于在测试期间当前网络使用的每秒
速率除以1000 Mbps以太网速率，可以证明当前校园网络使用每 秒位速率已达到12.431 Mbps。
7
在网络测试期间，从流量趋势图来看，流量峰值为1.877 MB， 网络中并未出现规律性的大流量突发现象；从数据包大小分布情 况来看，网络中产生的1024～1517 B的大包占用较多，为46.817 MB，说明网络存在大数据量的传输。
(3) 由于学校在放假期间校园网用户相对较少，在测试期间 客户端发起的连接请求数为824次，TCP连接会话峰值为37次/秒， 出现小规律性的突发。由于TCP会话数量较少，说明网络中不存 在DDoS攻击或TCP扫描现象。假如在开学期间学生用户上网较多 或受到黑客DDoS攻击，如不采取应急措施，网络会话连接数过多， 网关设备处理转发响应数据时CPU高负荷，导致网络瘫痪。
37.2.2 Top应用层协议分析 通过图37-6可以直观地得出网络中应用的情况，主要使用
UDP-Other、HTTP、TCP-Other等应用协议，可以进一步分析哪些 主机地址使用了这些应用。
CSNA网络分析认证专家实战案例(科来软件)章 (38)
第38章 某市供电局网络性能 分析报告
➢38.1 故障描述 ➢38.2 故障分析 ➢38.3 总结
1
38.1 故 障 描 述
某市供电局网络承载着各营业厅到省公司IDC的业务流量， 某些业务系统经常出现运行缓慢的情况，因此需要对网络承载业 务的性能进行评估。本次网络性能分析的网络部署如图38-1所示。
4～5
市供电局内部至 出口延时(毫秒)
<1
7
供电局出口至省公司广域网延时最大仅为7.65毫秒，90%都 在4～5毫秒之间，平均延时为4.5毫秒，性能相当不错；供电局 内部机器至出口的延时同样很小，基本都在1毫秒以内。
综上所述，市供电局至省公司的广域网延时、内部网络延时 都极小，性能良好，但连接成功率为94.3%，需要进一步分析产 生连接失败的原因；三次握手均为小包，需要进一步分析并判断 大包是否会丢失。
如图38-4所示，供电局客户端10.142.98.28给省公司服务器 10.142.1.227上传数据后，一直得不到对方确认，于是一直重传。 这属于供电局到省公司上传数据后的丢包现象。
网络中大包(≥512 B)的数量一共有4541 + 5085 + 167 242 = 176 868个，如图38-5所示。
网络中丢包次数一共为57 + 642 = 699个，如图38-6所示。
10
图38-4 11
图38-5 12
图38-6 以上两种丢包现象都会造成整个数据交互延时增大，影响用 户的体验。通过智能专家诊断系统发现，市供电局上传的数据在 广域网丢包的次数为57次，省公司下发的数据在广域网丢包的次 数为642次。考虑到丢失的包均为大包，因此大包丢包率为 0.395%(699/176 868)，远小于广域网可接受丢包率2%。
➢38.1 故障描述 ➢38.2 故障分析 ➢38.3 总结
1
38.1 故 障 描 述
某市供电局网络承载着各营业厅到省公司IDC的业务流量， 某些业务系统经常出现运行缓慢的情况，因此需要对网络承载业 务的性能进行评估。本次网络性能分析的网络部署如图38-1所示。
4～5
市供电局内部至 出口延时(毫秒)
<1
7
供电局出口至省公司广域网延时最大仅为7.65毫秒，90%都 在4～5毫秒之间，平均延时为4.5毫秒，性能相当不错；供电局 内部机器至出口的延时同样很小，基本都在1毫秒以内。
综上所述，市供电局至省公司的广域网延时、内部网络延时 都极小，性能良好，但连接成功率为94.3%，需要进一步分析产 生连接失败的原因；三次握手均为小包，需要进一步分析并判断 大包是否会丢失。
如图38-4所示，供电局客户端10.142.98.28给省公司服务器 10.142.1.227上传数据后，一直得不到对方确认，于是一直重传。 这属于供电局到省公司上传数据后的丢包现象。
网络中大包(≥512 B)的数量一共有4541 + 5085 + 167 242 = 176 868个，如图38-5所示。
网络中丢包次数一共为57 + 642 = 699个，如图38-6所示。
10
图38-4 11
图38-5 12
图38-6 以上两种丢包现象都会造成整个数据交互延时增大，影响用 户的体验。通过智能专家诊断系统发现，市供电局上传的数据在 广域网丢包的次数为57次，省公司下发的数据在广域网丢包的次 数为642次。考虑到丢失的包均为大包，因此大包丢包率为 0.395%(699/176 868)，远小于广域网可接受丢包率2%。
CSNA网络分析认证专家实战案例(科来软件)章 (34)
11
因此，我们断定服务器响应慢是由于客户端建立的TCP连接协 商的客户端窗口较小，导致TCP传输效率低下。
此外，我们将Win XP的TCP窗口改为固定值256进行测试， 发现应用延时大大增加(500～1000毫秒)，这进一步说明服务 器响应慢确实是由于客户端TCP窗口过小造成的。
12
34.2.2 分析结果 通过以上的分析步骤，我们可以得出结论：Win 7系统在
在“运行”中输入regedit，进入
14
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\T cpip\Parameters，新建一个DWORD，值名为TcpWindowSize， 值设置为15 000(10进制)。
(2) 保证服务器192.168.31.57与域的互通性，测试是否 为服务器自身原因导致。
通过本次故障分析我们发现，通过科来网络回溯分析系统 可以快速定位、分析、解决网络故障，大大提高我们的工作效 率。同时，借助科来网络回溯分析系统的大容量存储，可以方 便地对网络安全事件、网络攻击、偶发性故障等进行长期分析 和保存。
15
感谢
16
谢谢，精品课件
资料搜集
17
然后，我们对比Win 7客户端在域内和不在域内访问服务 器192.168.31.57的数据包，找到造成服务器响应慢的原因。 通过对数据包的各字段进行对比，最终我们发现两个通信过程 的区别如图34-3所示。
9
图34-3 10
从图34-3中可以明显看到，Win 7系统客户端在与服务器 建立连接时，不论是正常通信还是异常通信，客户端首次发送 的TCP同步包的TCP窗口大小默认都是8192；随后的TCP协商过 程中，异常TCP通信时客户端的TCP窗口大小锁定在256以下， 正常TCP通信时客户端的TCP窗口却锁定在了16 400左右，而 TCP窗口大小会直接影响到TCP传输速度。TCP窗口的工作机制 为滑动窗口，其主要作用是控制TCP的传输效率，它通过延时、 丢包、误码率、主机性能等参数动态调整窗口大小，窗口越大， TCP传输速率就越快，窗口越小，TCP传输速率就越慢。
因此，我们断定服务器响应慢是由于客户端建立的TCP连接协 商的客户端窗口较小，导致TCP传输效率低下。
此外，我们将Win XP的TCP窗口改为固定值256进行测试， 发现应用延时大大增加(500～1000毫秒)，这进一步说明服务 器响应慢确实是由于客户端TCP窗口过小造成的。
12
34.2.2 分析结果 通过以上的分析步骤，我们可以得出结论：Win 7系统在
在“运行”中输入regedit，进入
14
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\T cpip\Parameters，新建一个DWORD，值名为TcpWindowSize， 值设置为15 000(10进制)。
(2) 保证服务器192.168.31.57与域的互通性，测试是否 为服务器自身原因导致。
通过本次故障分析我们发现，通过科来网络回溯分析系统 可以快速定位、分析、解决网络故障，大大提高我们的工作效 率。同时，借助科来网络回溯分析系统的大容量存储，可以方 便地对网络安全事件、网络攻击、偶发性故障等进行长期分析 和保存。
15
感谢
16
谢谢，精品课件
资料搜集
17
然后，我们对比Win 7客户端在域内和不在域内访问服务 器192.168.31.57的数据包，找到造成服务器响应慢的原因。 通过对数据包的各字段进行对比，最终我们发现两个通信过程 的区别如图34-3所示。
9
图34-3 10
从图34-3中可以明显看到，Win 7系统客户端在与服务器 建立连接时，不论是正常通信还是异常通信，客户端首次发送 的TCP同步包的TCP窗口大小默认都是8192；随后的TCP协商过 程中，异常TCP通信时客户端的TCP窗口大小锁定在256以下， 正常TCP通信时客户端的TCP窗口却锁定在了16 400左右，而 TCP窗口大小会直接影响到TCP传输速度。TCP窗口的工作机制 为滑动窗口，其主要作用是控制TCP的传输效率，它通过延时、 丢包、误码率、主机性能等参数动态调整窗口大小，窗口越大， TCP传输速率就越快，窗口越小，TCP传输速率就越慢。
CSNA网络分析认证专家实战案例(科来软件)章 (42)
并在此后的80毫秒开始发送数据，服务器端响应比较正常，如图 42-6所示。
但我们在此会话中发现很多连续的ACK数据包，如图42-7所 示。
经分析，这是客户端对服务器端传输数据的确认，随机打开 一个确认数据包(编号1276)，见图42-8。
9
图42-5 10
图42-6 11
图42号和确认号可以分析出与该数据包相关联的数据包 (编号1207)，如图42-9所示。
14
图42-9 15
可以看到，编号为1276的数据包是对编号为1207的数据包进 行确认，两个包之间的时间相差700毫秒。
分析结论：客户端延迟。 问题出在客户端，客户端与OA相关的就是浏览器，问题可能 出在浏览器上。与客户沟通后了解到，网络中的浏览器种类、版 本较多，而访问慢的机器都是使用IE6浏览器，使用其他浏览器 时则访问速度正常。将某一问题机器的浏览器更新到IE7后，访 问速度恢复正常，如图42-10所示。后来询问OA系统开发人员， 证实该OA完全是在IE7的基础上开发的。
18
具体的客户端确认机制修改需在注册表中添加键值： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\Tcpip\Parameters\ Interfaces\Adapter GUID 键值名称为TcpDelAckTicks(不同的操作系统该值的名称不 尽相同)，数据类型为REG_DWORD，键值数据为0～6之间的值。 默认情况下，延迟ACK计时器值为200毫秒。如果将 TcpDelAckTicks 值设置为 0，则禁用延迟确认。
16
图42-10 17
42.2.3 关于小包太多的原因分析 客户端对服务器发送的每一个数据包都进行确认(ACK)，会
但我们在此会话中发现很多连续的ACK数据包，如图42-7所 示。
经分析，这是客户端对服务器端传输数据的确认，随机打开 一个确认数据包(编号1276)，见图42-8。
9
图42-5 10
图42-6 11
图42号和确认号可以分析出与该数据包相关联的数据包 (编号1207)，如图42-9所示。
14
图42-9 15
可以看到，编号为1276的数据包是对编号为1207的数据包进 行确认，两个包之间的时间相差700毫秒。
分析结论：客户端延迟。 问题出在客户端，客户端与OA相关的就是浏览器，问题可能 出在浏览器上。与客户沟通后了解到，网络中的浏览器种类、版 本较多，而访问慢的机器都是使用IE6浏览器，使用其他浏览器 时则访问速度正常。将某一问题机器的浏览器更新到IE7后，访 问速度恢复正常，如图42-10所示。后来询问OA系统开发人员， 证实该OA完全是在IE7的基础上开发的。
18
具体的客户端确认机制修改需在注册表中添加键值： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\Tcpip\Parameters\ Interfaces\Adapter GUID 键值名称为TcpDelAckTicks(不同的操作系统该值的名称不 尽相同)，数据类型为REG_DWORD，键值数据为0～6之间的值。 默认情况下，延迟ACK计时器值为200毫秒。如果将 TcpDelAckTicks 值设置为 0，则禁用延迟确认。
16
图42-10 17
42.2.3 关于小包太多的原因分析 客户端对服务器发送的每一个数据包都进行确认(ACK)，会
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
科来网络分析系统具备了行业领先的网络分析技术，它可以对当前复杂的网络进行精确 分析，为排查网络故障、提升网络安全、评估网络性能提供最全面和深入的数据依据，是网 络管理人员的必备工具。
科来网络分析系统的主要功能有： 分析网络中的流量占用情况；
‐3‐
分析内部网络和出口带宽的利用率情况； 分析网络中特定应用的数据通讯； 分析网络中特定主机的数据通讯； 分析网络中的异常数据通讯； 分析网络中的伪造IP和MAC地址攻击； 分析网络中的碎片和溢出攻击； 分析网络中的DOS/DDOS/DRDOS攻击； 分析网络中的TCP通信； 分析网络中的邮件收发是否正常； 分析网络中的DNS通讯是否正常； 分析网络中的HTTP网页访问是否正常； 分析网络中的MSN通讯是否正常； 网络中的Yahoo Message通讯是否正常； 分析网络中是否存在广播/组播风暴； 分析网络中传输的数据包是否正常； 分析网络的传输是否存在故障； 分析查找网络存在的环路故障； 分析查找网络中的蠕虫病毒攻击； 分析查找网络中感染病毒的机器； 分析查找网络速度慢故障； 分析查找网络时断时续故障； 分析查找内部用户无法上网故障； 分析网络中潜在的安全隐患； 分析查找网络中运行的扫描器以及扫描攻击；
‐4‐
科来网络分析系统
分析查找网络中暴力破解用户名与密码攻击； 分析查找网络中针对Web服务器的攻击； 分析查找网络中的网卡、线路以及对端设备速率故障； 分析查找网络中是否存在使用HTTP代理的程序，如QQ、MSN。Leabharlann 科来网络分析系统‐5‐
科来网络分析系统
3. 应用案例
3.1 案例分析 － 某中学网络故障诊断
网络的飞速发展给企业和用户带来了便利，但同时也对网络管理提出了严峻的挑战。局 域网内部以及局域网与互联网之间过多的数据通信，使网络及网络设备在负载、工作效率以 及安全性方面都承受着巨大的压力，网络时断时续、网络速度慢、网络遭受攻击却无法定位 攻击源等故障一直制约着网络的正常运行。在这种情况下，管理人员必须对网络的流量占用、 协议分布、通讯连接、数据包原始内容以及整个网络的运行情况了如指掌，才能在网络出现 时断时续、不能正常上网、遭受攻击故障出现时，快速准确地定位故障点并将其排除。
‐6‐
3.1.2 故障具体分析排查
科来网络分析系统
开始实际具体排查工作：
在主机房的客户机和以下的客户机上分别使用“arp –a”命令查看ARP缓存信息，结果 正常；登录中心交换机查看各端口的流量，由于交换机反应速度较慢，操作超时，无法获得 负载的实际流量；使用科来网络分析系统6.X捕获并分析网络中传输的数据包。
选择连接视图，发现在约2.5分钟的时间内网络中共发起了3027个连接，且状态大多都 是客户端请求同步，即三次握手的第一步，由TCP工作原理可知，TCP工作时首先通过三次握 手发起连接，如果请求端向不存在的目的端发起了同步请求，由于不会收到目的端主机的确 认回复，其状态将会一直处于请求同步直到超时断开，据此，我们现在更加断定校园网中存 在自动扫描攻击。
‐ 10 ‐
科来网络分析系统
（图5 192.168.101.57主机的通讯数据包信息） 在第一次和第二次捕获之间，相隔仅10分钟的时间，网络中就被新感染主机三台。由此 我们可以想象，如果不使用网络检测分析软件捕获分析网络中传输的数据包，仅通过查看交 换机的端口流量，或者使用单纯的流量软件，将很难找到问题的根源，这样网络中感染的主 机会越来越多，最终将导致整个网络的全部瘫痪。 以上便是使用科来网络分析系统6.x版诊断该校园网故障的全过程，在网络出现速度慢、 时断时续、不能访问时，网管人员均可使用这种方法对故障进行诊断排查。
科来网络分析系统
科来网络分析系统 应用案例
© 2009 科来软件保留所有权利 技术支持部 科来软件江苏办事处 电话：86-25-57921033 传真：86-25-57921033 网址： 技术论坛：
‐1‐
目录
3.1.1 故障描述
故障地点： 江苏省某中学校园网 故障现象： 严重网络阻塞，客户机之间相互ping时严重丢包，校园网用户访问互联网的速度非常慢， 甚至不能访问。 故障详细描述： 整个校园网突然出现网络通讯中断，内部用户均不能正常访问互联网，在机房中进行 ping包测试时发现，中心机房客户机对中心交换机管理地址的ping包响应时间较长且出现随 机性丢包，主机房客户机对二级交换机通讯的通讯丢包情况更加严重。 故障详细分析 前期分析 初步判断引起问题的原因可能是： 交换机ARP表更新问题 广播或路由环路故障 病毒攻击 需要进一步获取的信息： ARP信息 交换机负载 网络中传输的原始数据包
详细查看图1的连接信息，发现这些连接大多都是由192.168.5.119主机发起，即连接的 源地址是192.168.5.119。选中源地址是192.168.5.119的任意一个连接，单击鼠标右键，在 弹出的右键菜单中选择“定位浏览器节点>>端点1 IP”，这时节点浏览器将自动定位到 192.168.5.119主机。
‐2‐
1. 应用背景
科来网络分析系统
目前，计算机网络的发展异常迅猛，各政府部门和企事业单位，都大量通过网络进行信 息查询、邮件收发、数据共享等各种办公操作。由于计算机网络通信具备信息量大、更新速 度快、信息价值高、信息处理和利用方便等优点，使得计算机网络通信已逐渐成为企事业单 位日常工作不可或缺的一部份，整个社会已步入网络信息化时代。
2. 系统概述
科来网络分析系统是一个集故障诊断、安全分析、性能评估于一体的综合网络分析系统， 它通过捕获并分析网络中传输的底层数据包，有效反映网络通讯状况，帮助网络管理人员快 速准确定位故障点并解决网络故障，同时，系统的专家诊断功能，可以使不具备技术能力的 非技术人员，也能快速排查网络故障，从而规避网络安全风险，提高网络性能，增大网络可 用性价值，并确保整个网络的持续可靠运行。
‐7‐
科来网络分析系统
（图1 网络中的TCP连接信息） 选择图表视图，并选中TCP连接子视图项，查看192.168.5.119主机的TCP连接情况，如 图2所示。查看图2可知，192.168.5.119 这台主机在约2.5分钟的时间内发起 了2800个连接， 且其中有2793个连接都是初始化连接， 即同步连接，这表示192.168.5.119 主机肯定存在自 动扫描攻击。
科来网络分析系统
1. 应用背景...................................................................................................................... ‐ 3 ‐ 2. 系统概述...................................................................................................................... ‐ 3 ‐ 3. 应用案例...................................................................................................................... ‐ 6 ‐
XX中学校园网的主机约为1000台，一般情况下，同时在线的有600台左右。在停止捕获 后，我们在科来网络分析系统6.X主界面左边的节点浏览器中发现，内部网络（Private-Use Networks）同时在线的IP主机达到了6515台，如图1，这表示网络存在许多伪造的IP主机， 网络中可能存在伪造IP地址攻击或自动扫描攻击。
‐9‐
科来网络分析系统
（图4 192.168.4.34主机的TCP连接信息） 网管人员立即对新发现感染病毒的 3台主机进行隔离，ping测试响应时 间立刻变为1ms， 网络通讯立刻恢复正常。 在分析中，我们还发现，192.168.101.57主机占用的流量较大，其通讯数据包的源端和 目的端都使用UDP 6020端口，且与192.168.101.57通信的地址227.1.2.7是一个组播IP地址， 签于此，我们推测192.168.101.57可能在使用在线视频点播之类的应用，并因此对网络资源 造成了一定程度的耗费，其通讯数据包如图5所示。对于这种情况，网管人员也应对其进行 检查，确定其合法性，以避免网络带宽被 一些非关键业务所耗费。
网络中的数据传输是不透明的，在 不借助网络分析系统的情况下，很难 完成上述要求。 所以，随着网络规模的不断扩大和网络应用的不断增多，网络故障必将变得日益复杂，网络 攻击事件也必会不断增加。此时，保障整 个网络的持续可靠和安全运行，将 变得至关重要。 在这种大的网络环境下，网络分析系统的普及将成为必然。
（图2 192.168.2.119主机的TCP连接信息）
‐8‐
科来网络分析系统
选择数据包视图查看192.168.5.119传输数据的原始解码信息，如图3。从图3可知，这 些数据包的大小都是66字节，协议都是CIFS，源地址都是192.168.5.119，而目标地址则随 机产生，目标端口都是445，且数据包的TCP标记位都将同步位置1，这说明192.168.5.119 这台机器正在主动对网络中主机的TCP 445端口进行扫描攻击，原因可能是192.168.5.119 主机感染病毒程序，或者是人为使用扫描软件进行攻击。
（图3 192.168.2.119主机的数据包解码信息） 找到问题的根源后，正准备对192.168.5.119主机进行隔离，这时因其它事情中断分析 工作约10分钟左右。 继续工作，隔离192.168.5.119主机的同时再次将启动科来网络分析系统 6.x捕获分析网 络的数据通讯，约2.5分钟后停止捕获并分析捕获到的数据包。 分析捕获到的数据包，网络中又出现了3台与192.168.5.119相似情况的主机，且这些主 机发起的同步连接数都大大超过192.168.5.119，图4所示的即是其中一台主机在约2.5分钟 内的发起的连接数，其中同步连接达到了6431个。 通过这个情况，我们可以肯定192.168.5.119和新发现的三台主机都是感染了病毒，且 该病毒会主动扫描网络中其它主机是否打开TCP 445端口，如果某主机打开该端口，就攻击 并感染这台主机。如此循环，即引发了 上述的网络故障。
科来网络分析系统的主要功能有： 分析网络中的流量占用情况；
‐3‐
分析内部网络和出口带宽的利用率情况； 分析网络中特定应用的数据通讯； 分析网络中特定主机的数据通讯； 分析网络中的异常数据通讯； 分析网络中的伪造IP和MAC地址攻击； 分析网络中的碎片和溢出攻击； 分析网络中的DOS/DDOS/DRDOS攻击； 分析网络中的TCP通信； 分析网络中的邮件收发是否正常； 分析网络中的DNS通讯是否正常； 分析网络中的HTTP网页访问是否正常； 分析网络中的MSN通讯是否正常； 网络中的Yahoo Message通讯是否正常； 分析网络中是否存在广播/组播风暴； 分析网络中传输的数据包是否正常； 分析网络的传输是否存在故障； 分析查找网络存在的环路故障； 分析查找网络中的蠕虫病毒攻击； 分析查找网络中感染病毒的机器； 分析查找网络速度慢故障； 分析查找网络时断时续故障； 分析查找内部用户无法上网故障； 分析网络中潜在的安全隐患； 分析查找网络中运行的扫描器以及扫描攻击；
‐4‐
科来网络分析系统
分析查找网络中暴力破解用户名与密码攻击； 分析查找网络中针对Web服务器的攻击； 分析查找网络中的网卡、线路以及对端设备速率故障； 分析查找网络中是否存在使用HTTP代理的程序，如QQ、MSN。Leabharlann 科来网络分析系统‐5‐
科来网络分析系统
3. 应用案例
3.1 案例分析 － 某中学网络故障诊断
网络的飞速发展给企业和用户带来了便利，但同时也对网络管理提出了严峻的挑战。局 域网内部以及局域网与互联网之间过多的数据通信，使网络及网络设备在负载、工作效率以 及安全性方面都承受着巨大的压力，网络时断时续、网络速度慢、网络遭受攻击却无法定位 攻击源等故障一直制约着网络的正常运行。在这种情况下，管理人员必须对网络的流量占用、 协议分布、通讯连接、数据包原始内容以及整个网络的运行情况了如指掌，才能在网络出现 时断时续、不能正常上网、遭受攻击故障出现时，快速准确地定位故障点并将其排除。
‐6‐
3.1.2 故障具体分析排查
科来网络分析系统
开始实际具体排查工作：
在主机房的客户机和以下的客户机上分别使用“arp –a”命令查看ARP缓存信息，结果 正常；登录中心交换机查看各端口的流量，由于交换机反应速度较慢，操作超时，无法获得 负载的实际流量；使用科来网络分析系统6.X捕获并分析网络中传输的数据包。
选择连接视图，发现在约2.5分钟的时间内网络中共发起了3027个连接，且状态大多都 是客户端请求同步，即三次握手的第一步，由TCP工作原理可知，TCP工作时首先通过三次握 手发起连接，如果请求端向不存在的目的端发起了同步请求，由于不会收到目的端主机的确 认回复，其状态将会一直处于请求同步直到超时断开，据此，我们现在更加断定校园网中存 在自动扫描攻击。
‐ 10 ‐
科来网络分析系统
（图5 192.168.101.57主机的通讯数据包信息） 在第一次和第二次捕获之间，相隔仅10分钟的时间，网络中就被新感染主机三台。由此 我们可以想象，如果不使用网络检测分析软件捕获分析网络中传输的数据包，仅通过查看交 换机的端口流量，或者使用单纯的流量软件，将很难找到问题的根源，这样网络中感染的主 机会越来越多，最终将导致整个网络的全部瘫痪。 以上便是使用科来网络分析系统6.x版诊断该校园网故障的全过程，在网络出现速度慢、 时断时续、不能访问时，网管人员均可使用这种方法对故障进行诊断排查。
科来网络分析系统
科来网络分析系统 应用案例
© 2009 科来软件保留所有权利 技术支持部 科来软件江苏办事处 电话：86-25-57921033 传真：86-25-57921033 网址： 技术论坛：
‐1‐
目录
3.1.1 故障描述
故障地点： 江苏省某中学校园网 故障现象： 严重网络阻塞，客户机之间相互ping时严重丢包，校园网用户访问互联网的速度非常慢， 甚至不能访问。 故障详细描述： 整个校园网突然出现网络通讯中断，内部用户均不能正常访问互联网，在机房中进行 ping包测试时发现，中心机房客户机对中心交换机管理地址的ping包响应时间较长且出现随 机性丢包，主机房客户机对二级交换机通讯的通讯丢包情况更加严重。 故障详细分析 前期分析 初步判断引起问题的原因可能是： 交换机ARP表更新问题 广播或路由环路故障 病毒攻击 需要进一步获取的信息： ARP信息 交换机负载 网络中传输的原始数据包
详细查看图1的连接信息，发现这些连接大多都是由192.168.5.119主机发起，即连接的 源地址是192.168.5.119。选中源地址是192.168.5.119的任意一个连接，单击鼠标右键，在 弹出的右键菜单中选择“定位浏览器节点>>端点1 IP”，这时节点浏览器将自动定位到 192.168.5.119主机。
‐2‐
1. 应用背景
科来网络分析系统
目前，计算机网络的发展异常迅猛，各政府部门和企事业单位，都大量通过网络进行信 息查询、邮件收发、数据共享等各种办公操作。由于计算机网络通信具备信息量大、更新速 度快、信息价值高、信息处理和利用方便等优点，使得计算机网络通信已逐渐成为企事业单 位日常工作不可或缺的一部份，整个社会已步入网络信息化时代。
2. 系统概述
科来网络分析系统是一个集故障诊断、安全分析、性能评估于一体的综合网络分析系统， 它通过捕获并分析网络中传输的底层数据包，有效反映网络通讯状况，帮助网络管理人员快 速准确定位故障点并解决网络故障，同时，系统的专家诊断功能，可以使不具备技术能力的 非技术人员，也能快速排查网络故障，从而规避网络安全风险，提高网络性能，增大网络可 用性价值，并确保整个网络的持续可靠运行。
‐7‐
科来网络分析系统
（图1 网络中的TCP连接信息） 选择图表视图，并选中TCP连接子视图项，查看192.168.5.119主机的TCP连接情况，如 图2所示。查看图2可知，192.168.5.119 这台主机在约2.5分钟的时间内发起 了2800个连接， 且其中有2793个连接都是初始化连接， 即同步连接，这表示192.168.5.119 主机肯定存在自 动扫描攻击。
科来网络分析系统
1. 应用背景...................................................................................................................... ‐ 3 ‐ 2. 系统概述...................................................................................................................... ‐ 3 ‐ 3. 应用案例...................................................................................................................... ‐ 6 ‐
XX中学校园网的主机约为1000台，一般情况下，同时在线的有600台左右。在停止捕获 后，我们在科来网络分析系统6.X主界面左边的节点浏览器中发现，内部网络（Private-Use Networks）同时在线的IP主机达到了6515台，如图1，这表示网络存在许多伪造的IP主机， 网络中可能存在伪造IP地址攻击或自动扫描攻击。
‐9‐
科来网络分析系统
（图4 192.168.4.34主机的TCP连接信息） 网管人员立即对新发现感染病毒的 3台主机进行隔离，ping测试响应时 间立刻变为1ms， 网络通讯立刻恢复正常。 在分析中，我们还发现，192.168.101.57主机占用的流量较大，其通讯数据包的源端和 目的端都使用UDP 6020端口，且与192.168.101.57通信的地址227.1.2.7是一个组播IP地址， 签于此，我们推测192.168.101.57可能在使用在线视频点播之类的应用，并因此对网络资源 造成了一定程度的耗费，其通讯数据包如图5所示。对于这种情况，网管人员也应对其进行 检查，确定其合法性，以避免网络带宽被 一些非关键业务所耗费。
网络中的数据传输是不透明的，在 不借助网络分析系统的情况下，很难 完成上述要求。 所以，随着网络规模的不断扩大和网络应用的不断增多，网络故障必将变得日益复杂，网络 攻击事件也必会不断增加。此时，保障整 个网络的持续可靠和安全运行，将 变得至关重要。 在这种大的网络环境下，网络分析系统的普及将成为必然。
（图2 192.168.2.119主机的TCP连接信息）
‐8‐
科来网络分析系统
选择数据包视图查看192.168.5.119传输数据的原始解码信息，如图3。从图3可知，这 些数据包的大小都是66字节，协议都是CIFS，源地址都是192.168.5.119，而目标地址则随 机产生，目标端口都是445，且数据包的TCP标记位都将同步位置1，这说明192.168.5.119 这台机器正在主动对网络中主机的TCP 445端口进行扫描攻击，原因可能是192.168.5.119 主机感染病毒程序，或者是人为使用扫描软件进行攻击。
（图3 192.168.2.119主机的数据包解码信息） 找到问题的根源后，正准备对192.168.5.119主机进行隔离，这时因其它事情中断分析 工作约10分钟左右。 继续工作，隔离192.168.5.119主机的同时再次将启动科来网络分析系统 6.x捕获分析网 络的数据通讯，约2.5分钟后停止捕获并分析捕获到的数据包。 分析捕获到的数据包，网络中又出现了3台与192.168.5.119相似情况的主机，且这些主 机发起的同步连接数都大大超过192.168.5.119，图4所示的即是其中一台主机在约2.5分钟 内的发起的连接数，其中同步连接达到了6431个。 通过这个情况，我们可以肯定192.168.5.119和新发现的三台主机都是感染了病毒，且 该病毒会主动扫描网络中其它主机是否打开TCP 445端口，如果某主机打开该端口，就攻击 并感染这台主机。如此循环，即引发了 上述的网络故障。