欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

wireshark过滤器使用注意事项

作者:易隐者 发布于:2013-4-26 15:23 Friday 分类:网络分析

       以前一直认为各个网络分析产品的过滤器工作机制应该都是一样的,今天在协助分析定位一个故障的时候,我使用wireshark进行分析,用HTTP作为过滤条件,想仅查看HTTP交互的报文,其过滤后显示的内容如下图所示:

点击查看原图

       单看上图的显示内容,我们很容易的认为,这就是纯粹的HTTP交互,但是未看见三次握手连接建立的过程,一开始我心里是有点疑惑,但是并未往心里去,后来在合作伙伴的提醒下,我再尝试使用TCP作为过滤条件,方才看到大量的SYN报文,如下图所示:

点击查看原图

         实在想不通,难道HTTP的三次握手过程不属于HTTP报文????不知道wireshark在这一块是如何设计和考虑的,总之个人认为这个设计不合常理。我们以后在使用wireshark过滤器的时候稍微注意一下,避免出现误解。

阅读全文>>

标签: TCP wireshark 过滤器 HTTP

评论(2) 引用(0) 浏览(9154)

策略误报导致应用保存失败的分析案例

作者:易隐者 发布于:2013-4-20 14:13 Saturday 分类:案例讨论

       某用户应用,需要将一些修改信息提交保存至业务服务器,在这个保存过程中出现无法保存的现象(保存失败,点击保存按钮后,IE页面进度条长时间处于加载状态),我出于帮忙,到用户现场捕获了业务保存时的交互报文,如下图所示:
点击查看原图

       查看这个交互的过程,我们可以非常清晰的看到,客户端与服务器TCP三次握手正常,问题出在客户端提交POST请求的报文被中间设备丢弃了。比较有趣的是,客户端在尝试两次重传之后,较为聪明的将这个POST请求字段(长度为859B)拆分为两个长度分别为536B和323B的字段,并先将长度为536B的应用字段重传给服务器,我们清楚的看到服务器对这个应用字段作出了确认,这说明这个长度的应用字段正常到达了应用服务器,但是后续长度为323B的应用字段一直被丢弃,这很容易想到是中间设备策略误报一直丢弃某些固定报文导致的,我们来看一下这个应用字段里到底封装的是什么应用数据,我们首先看这个报文的应用字段解码如下:

点击查看原图

       这个看得有点头晕,我们将这段字符解码一下,如下图所示:
点击查看原图
       解码之后,我们可以看到这个应用字段中存在“varchar(60)”等关键字,这可能引起WAF、IPS等设备将此报文误报为SQL注入的尝试。      

阅读全文>>

标签: 应用故障 IPS 策略误报 POST WAF SQL注入

评论(7) 引用(0) 浏览(5431)

《某公司QQ掉线分析案例》之我见

作者:易隐者 发布于:2013-4-14 17:52 Sunday 分类:案例讨论

       前段时间看到CSNA论坛上有一篇QQ掉线故障分析的案例,原文是PDF格式的,我就不转载其全文了,其链接如下 : http://www.csna.cn/network-analyst-50520-1-1.html,大家可自行通过上述链接下载查看。

       大致看了分析过程之后,觉得其中存在一些疑问,特地找时间针对这个案例做一个大致的分析,以便大家讨论参考。原本准备做相关交互图示的,由于个人时间问题,这次就免了,还望各位见谅。

1, QQ多人同时掉线,大约1秒就自动连上,浏览网页和其他应用没有问题  

       QQ属于一种终端的应用,一般情况下,局域网内某应用出现同时掉线、缓慢等问题,基本上可以排除是单个终端的问题,因为从这个现象上来看,这是一个全局问题,可能是业务应用本身、业务服务器或者承载业务的网络系统出现了问题。在此故障分析案例中,作者提到QQ同时掉线但是浏览网页和其他应用没有问题。通过这个故障现象的描述,我个人首先可能会想到整个互联网出口是否会出现网络瞬间中断的情况?这是我个人的猜想,因为如果真是互联网出口出现网络瞬间中断,那么HTTP等基于TCP的应用由于TCP的重传机制,在出口网络中断1秒左右的时间内,终端使用者不会有明显的异常感受,而基于UDP等应用,可能会出现掉线等现象,在网络出口恢复正常之后,QQ再次自动上线。这个猜想的原因至少可以很好的解释该案例作者一开始描述的故障现象。

2, QQ掉线是QQ服务器主动RST连接导致的,腾讯给出的解释是由于用户端IP地址出现了变化。

1),QQ大部分情况下应该是使用UDP协议的,少数情况下使用TCP协议。

       QQ是一个较为复杂的应用,其为了满足使用者在各种复杂的环境对QQ的正常使用,其会存在多种模式和网络交互行为,大部分情况下,QQ默认会使用UDP协议进行交互,少数情况下会使用TCP甚至TCP的80端口、443端口进行交互,特殊情况下,根据需要和设置,其还可以通过代理的方式进行交互。

       正是QQ这种特殊应用工作机制的多样性和复杂性,导致我们在遇到其故障时,给我们的分析定位带来了难度。在该案例中,由于QQ是大规模的出现掉线现象,我们在分析处理时,其实根本搞不清楚不同使用者的QQ到底是工作在何种模式之下,其网络行为特征千差万别,因此,我们很难通过某一台测试机来全面分析验证QQ故障的原因。

       在该案例中,测试机的QQ似乎使用的是TCP443端口进行交互的,但其实绝大部分情况下,QQ都是基于UDP协议进行交互的。因此在此案例中,按照我个人较为严谨的分析习惯,测试机的选择非常值得做进一步的商榷。

2),就算这个客户网络中所有使用的QQ都是基于TCP协议的,如果真是如腾讯所说,是由于QQ服务器发现用户IP出现了变化,才向客户端发送RST报文的,那么:

       其一,不同的QQ客户端与QQ服务器是单独建立连接的,暂且不论QQ服务器的多样性(不同的QQ客户端很可能会与网络中的N个不同的QQ服务器之间建立交互链接),不同的QQ客户端与QQ服务器之间建立不同的交互连接,那么即使防火墙在做NAT时出现BUG,突然改变了某些已有连接的源IP地址,也应该绝少出现同时改变N个不同QQ客户端与服务器之间已有连接的源IP,换句话说,如果原因真是如该案例作者所说,很难解释QQ同时掉线的现象。
       其二,那么我们站在QQ服务器的角度来分析一下此种情况真的发生时,QQ服务器会作何处理?QQ服务器收到源IP地址变化的QQ客户端报文后,QQ服务器会把他作为一个新的TCP连接来处理(因为五元组不一样),而QQ服务器并没有这个TCP连接信息,因此服务器会直接RST该报文,而这种RST报文,其ACK位肯定不会置一的,但是我们看到这个案例中作者的截图如下:
 点击查看原图

该RST报文ACK位是置一的,因此这个RST报文并不是如作者想象的情况下产生的。

       其三,我们再来看另外一张截图:

点击查看原图
        看此交互截图,QQ服务器已经对客户端的报文作出了确认(序号2230的包),紧接着(0.000045秒后),QQ服务器向客户端发送RST报文(序号 2232的包),这个报文可以肯定在服务器紧接着发出序号2230的包之后发出的,如果按照作者的说法,RST报文至少应该是序号为2231的客户端报文经防火墙源地址转换之后(源IP变化),到达QQ服务器,QQ服务器发现源地址变化,再向客户端发送RST报文,这样整个过程方才合理,但是上面这张截图已经充分说明:事实并非如此。

3,如果真的是防火墙的NAT出现了这种低级的错误和BUG,那么对用户影响最大的应该是HTTP等基于TCP应用。因为很多HTTP应用的动态口令、验证码等都需要通过数个不同的TCP连接与服务器进行交互,一旦出现该案例作者所说的防火墙处理BUG,将导致这些应用出现访问故障。而不会仅仅是无关紧要的QQ应用出现问题。

4,QQ掉线而其他TCP应用正常,很可能是防火墙的UDP会话保持时间过短导致的。

       因为很多人挂QQ并不一直与好友聊天。而一般情况下,防火墙等为节约设备资源,会将UDP的会话超时时间设置为一个较短的数值,如60秒,那么如果用户在这个超时时间内无任何数据交互的话,防火墙会将这个UDP会话从防火墙连接表中删除,当QQ客户端再次尝试与QQ服务器交互时,其发送的QQ状态更新报文就会被防火墙丢弃,导致QQ客户端掉线。QQ掉线后,客户端会再次发起新的连接,此时防火墙将其作为一个新建的UDP连接进行处理,QQ因此再次成功上线。当然这个很难解释QQ同时掉线的现象。

       另外一种情况是,如果防火墙的UDP连接表出现异常,防火墙突然清空其UDP连接表,也可能会导致该案例中故障现象的产生。

5,在NAT POOL情况下,NAT设备会根据不同的算法(基于源IP的、基于连接的等)实现NAT POOL的地址复用,大部分算法应该都是基于源IP等计算的,如果是基于数据包、连接等进行计算,则很可能会导致各种问题的产生,我以前有一个非常经典的案例——《移动无线VPN客户端隧道建立故障分析》,下次我发布到我的博客,大家可去参考。 

简单总结:

       防火墙在NATPOOL情况下,变化地址是正常的,关键看防火墙的NAT算法。QQ掉线应该跟这个无关,案例中分析来自于QQ服务器的RST报文跟NAT后源地址变化无关。

阅读全文>>

标签: TCP RST 五元组 重传机制 防火墙 BUG NAT QQ掉线

评论(3) 引用(0) 浏览(13983)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1