网络分析方法与实例

“网络分析方法与实例”王超[e-mail]@qq.com9月9日@合肥——网络分析技术交流方法篇对比分析法对比分析法就是在中间设备两端（数据包的进口、数据包转发口）同时抓包，并对进出口处所抓取到的数据包做相应的对比，从而发现中间设备对相应数据包的处理情况，包括更改、丢弃、转发以及经过中间设备后的延时等。关联分析法关联分析法是指，一个数据包或数据流在经过一个中间设备时，被中间设备做了更改，我们利用数据包的IP标识、应用层字段、数据流的五元组等特性，将中间设备前后的数据包、数据流对应起来的方法。TIPS:另外一种对比分析法除了我们这里描述的对比分析法外，还有另外一个较为常用的对比分析方式，那就是将异常时的数据交互过程跟正常时的数据交互过程进行对比分析，从而发现异常时数据交互的问题所在对比分析法-原理当一个目的地址不是中间设备的数据包进入一个中间设备时，它必然会被中间设备转发到其某一个出口对比分析法-应用范围1分析设备转发延时对比分析法-应用范围2分析设备是否丢包对比分析法-应用范围3分析中间设备对数据包的更改当一个数据包进入一个中间设备之后，中间设备可能对该数据包做相应的改动后，再将其向外转发出去，很多情况下，这种改动对网络数据交互是没有什么影响的，如路由对数据包的NAT处理，但是有的时候，某些更改就有可能给网络数据交互带来某些难以预料的后果，如将数据包的TCP窗口改小、修改TCP的选项等。我们在分析的过程中，主要关注中间设备对数据包做了哪些更改以及这些更改可能给网络数据交互带来的后果，主要包括数据包源IP地址、目的IP地址、IP标识、源端口、目的端口、数据包窗口大小、TCP选项、数据包有效载荷大小等。对比分析法-应用范围4分析异常时与正常时的差异（基于基线）时间下班期间衡量参数值上班期间正常行为基线异常行为结合各种网络或业务系统的运行基线，我们通过将异常时的网络交互情况与正常时的网络交互基线参数数值进行对比分析，可以帮助我们快速发现业务异常以及可能的原因。另外，还有基于网络行为基线的对比分析方式关联分析法-原理1IP标识关联很多中间设备在处理数据包的过程中，一般不会修改数据包的IP标识字段，那么，我们就可以通过分析进出中间设备数据包的IP标识字段是否一致来判断是否属于同一个数据包关联分析法-原理2五元组关联我们在一个交换或纯路由（无NAT）的环境下做对比分析时，可以利用五元组来快速的将不同位置处抓取的数据流关联起来，因为在交换或纯路由的环境下，数据报头的五元组信息不会被更改关联分析法-原理3应用层关键字段关联由于应用层数据是端系统来处理的，因此绝大多数的中间设备在转发数据包时，仅仅会针对数据包的链路层、网络层和传输层的信息进行更改一般不会对应用层的数据进行修改。我们可以利用这个应用层数据的一些特征进行关联。关联分析法-应用范围•对比分析前•应用交互的关联•多层架构的业务应用中的关联分析案例案例1-国税防火墙FTPbug案例2-地税网上申报业务系统故障案例1-故障环境说明：1、客户端的默认网关是主路由器2、主路由上设置了相应的策略，凡是FTP/HTTP的应用均交由备路由处理3、备路由上会将访问国家局的网段指向国家局路由4、核心与路由间均部署防火墙，防火墙工作在透明模式下5、客户端访问服务器的数据流走向比较复杂，看演示思考：服务器回包的数据流走向是如何的？案例1-故障现象•省局到国家局的FTP服务很慢，一般需要40多秒才可以登陆上去，有时根本登陆不上去•Ping测试延时很小•省局到国家局的HTTP应用正常案例1-前期简单分析•Ping延时很小，说明网络层的延时很正常•网络环境复杂，数据流走向复杂，数据包来回路径不一致，中间经过2台防火墙，可能存在状态检测的问题•HTTP的数据流走向跟FTP的数据流走向应该是一样的，HTTP正常，FTP不正常，说明这个跟TCP的状态检测无关，应该是FTP应用层的问题•暂时没什么头绪，只能先从客户端下手，进行抓包分析，看看大体的情况案例1-登陆不上时的数据包分析TCP三次握手建立连接S响应：winsockreadyC输入用户名C用户名第一次重传2.9S的延时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响应：winsockreadyC输入用户名C用户名第一次重传C用户名第二次重传C对”S第一次重传“的确认C对”S第二次重传“的确认S的第一次重传S的第二次重传S：用户名ok，需密码S“需密码”第一次重传C输入密码C密码第一次重传C密码第二次重传S“需密码”第二次重传C密码第三次重传S：登陆成功29.9S的延时23.9S的延时11.9S的延时5.8S的延时2.8S的延时案例1-交互过程示意图用户名请求用户名请求用户名用户名请求用户名请求用户名用户名请求用户名请求用户名请求用户名请求用户名S：winsockreadyC输入用户名C用户名第一次重传C用户名第二次重传S的第一次重传S的第二次重传S的第三次重传结论：客户端传输用户的数据包被中间设备丢掉了！定位是什么设备丢包对比分析法：通过抓取中间设备进出口的数据包，结合数据包内IPID、五元组、内容等信息来判断是否属于同一会话，是否有数据包被丢弃双网卡笔记本安装科来开启两个工程，分别针对中间设备进出口抓包TAPTAP其实我们也可以利用中间设备本身自带的抓包功能进行分析和定位，具体可以参考我以前写的PPT：《疑难故障解决实例》通过此种方法，我们定位出是防火墙丢包！案例1-防火墙丢包原因分析TIPS:防火墙中的两个概念状态检测：深度检测：原因分析：1，数据包来回路径肯定是不一致的，那么对于基于状态检测的防火墙，是不会建立TCP连接的但是HTTP应用正常，抓包显示FTP三次握手的过程也很正常，说明跟TCP状态检测无关2，抓包分析我们可以发现被丢弃的包都是FTP传输用户名和密码的包，这个肯定属于FTP应用层的包，防火墙丢弃FTP应用层的数据包，那么问题应该就出在防火墙的FTP应用层检测上案例1-故障解决故障解决：1，在防火墙上取消FTP应用绑定，让防火墙不要对FTP的数据包进行深度的过滤和检测2，测试，FTP登陆正常思考：除了在防火墙上取消针对FTP应用的应用层深度检测功能外，还有其他的解决方式吗？提示：大家注意数据包中的ICMP重定向报文案例2-故障环境说明:1，网上申报服务器的地址是192.168.1.1，经过网闸后转换为X.X.16.73；2，前置机的IP地址为X.X.16.56，征管服务器的IP地址为X.X.16.200。业务访问流程：1，纳税人通过互联网登陆网上申报服务器，提交相关纳税信息；2，网上申报服务器将这些纳税信息转发给前置机的同时，将相关信息写入征管服务器数据库；3，网上申报服务器与前置机的数据交互出现问题，那么网上申报服务器会将征管服务器数据库相关的信息锁死拓扑：案例2-故障现象故障现象：1，网上申报业务系统运行时，每天总有一部分纳税人的申报表单数据无法正常上传，可以通过征管服务器的业务软件看到这些用户的申报数据处于锁状态；2，在没有网闸的情况下，网上申报服务器与前置机直接通讯，则故障现象消失，网上纳税全部正常。案例2-故障分析前期分析1，结合故障现象与业务流程，我们可以清晰的发现，问题应该就是出现在网上申报服务器经过网闸的地址转换后与前置机交互的过程。2，在网上申报服务器不通过网闸的地址转换而是直接与前置机交互的时候，业务应用一切正常，那么，是网闸在做地址转换的时候对某些数据报文做了修改或者是网闸直接丢弃了某些业务报文导致的故障吗？3，网闸是最为可疑的故障关键点，我们决定在网闸前后部署网络分析系统（在此环境下，可直接在申报服务器上和前置机上分别安装网络分析系统），对网上申报业务数据交互过程分别进行抓包，如下图所示：数据分析-发现异常TCP会话我们通过科来网络分析系统捕获前置机交互的数据包，一段时间后，我们在“TCP会话”视图中，发现有几个TCP会话持续的时间比一般的TCP会话长很多，如下图所示：这几个TCP会话持续的时间均超出其他的会话很多异常会话交互过程分析网闸地址73首先发送RESET报文网闸地址向前置机发送（重传）报文，前置机直接发送RESET报文重置连接。这个过程，导致了该TCP会话持续时间很长。第一个reset报文解码这个数据报文的源MAC地址并非网闸的MAC，真实的网闸MAC地址是00:40:63:EF:43:DF为什么网闸的MAC发生了变化？难道网内存在会话劫持？查看整个交互过程的MAC变化网闸源MAC为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的原因InternetAddressPhysicalAddressTypeX.X.16.7300-21-5E-82-AF-86dynamicTIPS：ARP表的更新实际环境中，只有同时满足以下两个条件时，设备的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表更新的原因我们在科来网络分析系统的“数据包”视图查看交互过程的所有数据报文来自MAC地址为00-21-5E-82-AF-86的ARP响应到达了前置机，前置机更新其ARP表项前置机向网络中发送ARP请求，请求网闸IP对应的MAC前置机在收到来自网闸的数据报文之后，都向00-21-5E-82-AF-86地址发送确认报文网闸、前置机以及未知设备的数据交互情况和状态变化网络分析学习相关资料《TCP/IP详解卷1》《Advanced.Network.Analysis.Techniques》LauraChappell《snifferuniversity》sniffer大学培训课程wiresharkuniversitywireshark大学培训课程laura《TCP-IPAnalysisandTroubleshooting》《TCP.IP.Analysis.And.Troubleshooting.Toolkit》KevinBurns著战晓苏张敏译《实用网络流量分析技术》高彦刚《网络分析方法和实例》王超王超电话：[phone]QQ：349932999邮件：[e-mail]网站：自由问题讨论