网络分析方法与实例

《网络分析方法与实例》由会员分享，可在线阅读，更多相关《网络分析方法与实例（33页珍藏版）》请在金锄头文库上搜索。

1、“网络分析方法与实例”王超 9月9日 合肥网络分析技术交流方法篇p对比分析法对比分析法就是在中间设备 两端（数据包的进口、数据包转发 口）同 时 抓包，并对进 出口处所抓取到的数据包做相应的对比，从而发现 中间 设 备对 相应数据包的处理情况，包括更改、丢弃、转发 以及经过 中间设 备 后的延时等。p关联分析法关联分析法是指，一个数据包或数据流在经过 一个中间设备时 ，被中 间 设备 做了更改，我们利用数据包的IP标识 、应用层字段、数据流的五 元 组等特性，将中间设备 前后的数据包、数据流对应 起来的方法。 TIPS:另外一种对对比分析法除了我们这 里描述的对比分析法外，还有另外一个较为

2、 常用的对比 分析方式，那就是将异常时的数据交互过程跟正常时的数据交互过程进 行对比分析，从而发现 异常时数据交互的问题 所在 对比分析法-原理当一个目的地址不是中间设备 的数据包进入一个中间 设备时 ，它必然会被中间设备转发 到其某一个出口 对比分析法-应用范围1p 分析设备转发延时对比分析法-应用范围2p分析设备是否丢包对比分析法-应用范围3p 分析中间设备对数据包的更改当一个数据包进入一个中间设备之后，中间设备可能对该数 据包做相应的改动后，再将其向外转发出去，很多情况下， 这种改动对网络数据交互是没有什么影响的，如路由对数据 包的NAT处理，但是有的时候，某些更改就有可能给网络数 据交

3、互带来某些难以预料的后果，如将数据包的TCP窗口改 小、修改TCP的选项等。我们在分析的过程中，主要关注中 间设备对数据包做了哪些更改以及这些更改可能给网络数据 交互带来的后果，主要包括数据包源IP地址、目的IP地址、IP 标识、源端口、目的端口、数据包窗口大小、TCP选项、数 据包有效载荷大小等。 对比分析法-应用范围4p 分析异常时与正常时的差异（基于基线）时间下班期间衡量参数值上班期间正常行为基线异常行为结合各种网络或业务 系统的运行基线，我们通过将异常时的网络交互情况 与正常时的网络交互基线参数数值进 行对比分析，可以帮助我们快速发现 业务 异常以及可能的原因。另外，还有基于网络行为基

4、线的对比分析方式关联分析法-原理1p IP标识关联很多中间设备 在处理数据包的过程中，一般不会修改数据 包的IP标识字段，那么，我们就可以通过分析进出中间设 备数据包的IP标识字段是否一致来判断是否属于同一个数据 包 关联分析法-原理2p 五元组关联我们在一个交换或纯路由（无NAT）的环境下做对比分析时， 可以利用五元组来快速的将不同位置处抓取的数据流关联起来 ，因为在交换或纯路由的环境下，数据报头的五元组信息不会 被更改 关联分析法-原理3p 应用层关键字段关联由于应用层数据是端系统来处理的，因此绝大多数的中间设 备在转发数据包时，仅仅会针对数据包的链路层、网络层和 传输层 的信息进行更改一

5、般不会对应用层的数据进行修改。 我们可以利用这个应用层数据的一些特征进行关联。关联分析法-应用范围对比分析前应用交互的关联多层架构的业务应用中的关联分析案例p案例1-国税防火墙FTP bugp案例2-地税网上申报业务系统故障案例1-故障环境说明： 1、客户端的默认网关是主 路由器 2、主路由上设置了相应的 策略，凡是FTP/HTTP的 应用均交由备路由处理 3、备路由上会将访问国家 局的网段指向国家局路由 4、核心与路由间均部署防 火墙，防火墙工作在透明 模式下 5、客户端访问服务器的数 据流走向比较复杂，看演 示思考： 服务器回包的数据流走向是如何的？案例1-故障现象省局到国家局的FTP服务

6、很慢，一般需要40多 秒才可以登陆上去，有时根本登陆不上去Ping测试延时很小省局到国家局的HTTP应用正常案例1-前期简单分析Ping延时很小，说明网络层的延时很正常网络环境复杂，数据流走向复杂，数据包来回路径不 一致，中间经过2台防火墙，可能存在状态检测的问 题HTTP的数据流走向跟FTP的数据流走向应该是一样 的，HTTP正常，FTP不正常，说明这个跟TCP的状 态检测无关，应该是FTP应用层的问题暂时没什么头绪，只能先从客户端下手，进行抓包分 析，看看大体的情况案例1-登陆不上时的数据包分析TCP三次握手建立连接S响应：winsock readyC输入用户名 C用户名第一次重传2.9S

7、的延时S的第一次重传S的第二次重传C用户名第二次重传 C用户名第三次重传S的第三次重传C用户名第四次重传S：用户名ok，需密码C输入密码S：超时关闭S“需密码”重传C重传密码5.9S的延时12S的延时23.9S的延时23.9S的延时6S的延时15.8S的延时C对”S第一次重传“的确认C对”S第二次重传“的确认C对”S第三次重传“的确认案例1-登陆成功，但是很慢的数据包分析TCP三次握手建立连接S响应：winsock readyC输入用户名C用户名第一次重传C用户名第二次重传C对”S第一次重传“的确认C对”S第二次重传“的确认S的第一次重传S的第二次重传S：用户名ok，需密码S“需密码”第一次重

8、传C输入密码C密码第一次重传C密码第二次重传S“需密码”第二次重传C密码第三次重传S：登陆成功29.9S的延时23.9S的延时11.9S的延时5.8S的延时2.8S的延时案例1-交互过程示意图用户名请求用户名请求用户名用户名请求用户名 请求用户名用户名请求用户名 请求用户名请求用户名请求用户名S：winsock readyC输入用户名C用户名第一次重传C用户名第二次重传S的第一次重传S的第二次重传S的第三次重传结论：客户端传输用户的数据包被中间设备丢掉了！定位是什么设备丢包对比分析法： 通过抓取中间设备进出口的数 据包，结合数据包内IPID、五 元组、内容等信息来判断是否 属于同一会话，是否有

9、数据包 被丢弃双网卡笔记本安装科来 开启两个工程，分别针 对中间设备进出口抓包TAPTAP其实我们也可以利用中间设备本 身自带的抓包功能进行分析和定 位，具体可以参考我以前写的 PPT：疑难故障解决实例通过此种方法，我们定位 出是防火墙丢包！案例1-防火墙丢包原因分析TIPS:防火墙中的两个概念 状态检测： 深度检测：原因分析： 1，数据包来回路径肯定是不一致的，那么对于基于状态检测的 防火墙，是不会建立TCP连接的但是HTTP应用正常，抓包显示 FTP三次握手的过程也很正常，说明跟TCP状态检测无关 2，抓包分析我们可以发现被丢弃的包都是FTP传输用户名和密 码的包，这个肯定属于FTP应用层

10、的包，防火墙丢弃FTP应用 层的数据包，那么问题应该就出在防火墙的FTP应用层检测上案例1-故障解决故障解决： 1，在防火墙上取消FTP应用绑定，让防火墙不要对FTP的 数据包进行深度的过滤和检测 2，测试，FTP登陆正常思考： 除了在防火墙上取消针对FTP应用的应用层深度检测功能 外，还有其他的解决方式吗？ 提示： 大家注意数据包中的ICMP重定向报文案例2-故障环境说说明:n1，网上申报服务器的地址是192.168.1.1，经过网闸后转换 为X.X.16.73；n2，前置机的IP地址为X.X.16.56，征管服务器的IP地址为 X.X.16.200。业务访问业务访问 流程：p1，纳税人通过

11、互联网登陆网上申报服务器，提交相关纳税 信息；p2，网上申报服务器将这些纳税信息转发给 前置机的同时， 将相关信息写入征管服务器数据库；p3，网上申报服务器与前置机的数据交互出现问题 ，那么网 上申报服务器会将征管服务器数据库相关的信息锁死 拓扑：案例2-故障现象故障现现象：p1，网上申报业务 系统运行时，每天总有一 部分纳税人的申报表单数据无法正常上传， 可以通过征管服务器的业务软 件看到这些用 户的申报数据处于锁状态；p2，在没有网闸的情况下，网上申报服务器 与前置机直接通讯，则故障现象消失，网上 纳税全部正常。案例2-故障分析前期分析p1，结合故障现象与业务 流程，我们可以清晰的发现 ，

12、问题应该 就是出 现在网上申报服务器经过 网闸的地址转换 后与前置机交互的过程。p2，在网上申报服务器不通过网闸的地址转换 而是直接与前置机交互的时 候，业务应 用一切正常，那么，是网闸在做地址转换 的时候对某些数据报 文做了修改或者是网闸直接丢弃了某些业务报 文导致的故障吗？p3，网闸是最为可疑的故障关键点，我们决定在网闸前后部署网络分析系 统（在此环境下，可直接在申报服务器上和前置机上分别安装网络分析系 统），对网上申报业务 数据交互过程分别进 行抓包，如下图所示： 数据分析-发现异常TCP会话我们通过科来网络分析系统捕获前置机交互的数据包，一段时间 后，我们 在“TCP会话” 视图 中，

13、发现 有几个TCP会话持续的时间 比一般的TCP会话 长很多，如下图所示： 这几个TCP 会话持续的 时间 均超出 其他的会话 很多异常会话交互过程分析网闸闸地址73首先 发发 送RESET报报文 网闸闸地址向前置机发发 送（重传传）报报文，前 置机直接发发送RESET 报报文重置连连接。 这这个过过程，导导致了该该 TCP会话话持续时间续时间 很 长长。第一个reset报文解码这个数据报文的源MAC地址并 非网闸的MAC，真实的网闸 MAC地址是00:40:63:EF:43:DF 为为什么网闸闸的MAC发发生了变变化？难难道网内存在会话话劫持？查看整个交互过程的MAC变化网闸闸源MAC为为

14、00:40:63:EF:43:DF前置机发发往网闸闸的确认认数据 报报文，封装的目的MAC却是 00:21:5E:82:AF:86MAC为为00:21:5E:82:AF:86的 设备设备 以网闸闸的IP向前置机发发 送RESET报报文在交互的过程中，前置机将发给网闸地址的确认报文，封装了一个非网闸的MAC 地址00:21:5E:82:AF:86 ，为为什么会突然出现现了这这种改变变呢？前置机封装错误目的MAC的原因Internet Address Physical Address TypeX.X.16.73 00-21-5E-82-AF-86 dynamicTIPS：ARP表的更新 实际环 境

15、中，只有同时满 足以下两个条件时，设备 的ARP表项才会更新： 1，设备 收到来自某IP的ARP请求包或免费ARP包； 2，设备 的现有ARP表项中已经存在该IP对应 的ARP表项。 其他的非ARP报文不会对设备 的ARP表项产 生影响。一般而言，主机是根据其ARP表项来封装要发送的数据报文的目的MAC 地 址，那么，这里前置机发往网闸数据报文的目的MAC地址出现改变是否 是因为前置机的ARP表项内容变化了呢？我们在前置机的DOS窗口下， 使 用arp a命令查看异常时的arp表项内容，发现 网闸IP对应 的MAC地址的 确变成了00:21:5E:82:AF:86。前置机ARP表更新的原因我们

16、在科来网络分析系统的“数据包”视图查 看交互过程的所 有数据报文 来自MAC地址为00-21-5E-82- AF-86的ARP响应到达了前置 机，前置机更新其ARP表项 前置机向网络中发送ARP请 求，请求网闸IP对应 的MAC 前置机在收到来自网闸的数据 报文之后，都向00-21-5E-82- AF-86地址发送确认报 文 网闸、前置机以及未知设备的数据交互情况和状态变化 网络分析学习相关资料pTCP/IP详解卷1 pAdvanced.Network.Analysis.TechniquesLaura Chappellpsniffer university sniffer大学培训课程 p wireshark university wireshark大学培训课程 laurapTCP-IP Analysis and Troubleshooting pTCP.IP.Analy