微信号:dellemc_tech

介绍:为戴尔易安信客户提供技术支持服务,为广大IT行业用户分享技术文章与行业信息。

【大咖讲网络】谁动了我的网络

2017-07-24 16:18 林沛满

作为中国网民,我们享有学习网络知识的天然优势,这是很多老外一辈子都不敢奢望的。还记得刚学会上网的时候,某知名搜索网站突然就连不上了,有位学长说这是域名被封,直接连IP就可以了,还帮我修改了hosts文件。于是我沿着这个方向研究,很快就理解了DNS协议。在实践中学到的本领,比捧着课本背诵的不知道高到哪里去。


又过了一阵,竟然连IP都连不上了。我在探索过程中,又学会了HTTP代理和VPN等科学上网技术。就这样,十几年下来身经百战,不知不觉中掌握了很多网络技术,每天都能到外网和同行们谈笑风生。现在回忆起来,我的知识真没多少是刻意去学的,而是在和网络问题斗争时被动学会的。被虐久了还得了斯德哥尔摩综合症,去年到国外出差了一个月,便觉得食不知味,因为根本找不到学习的机会。回到国内赶紧打开浏览器,Duang~~立即弹出运营商推送的广告。还是那个熟悉的味道,回家的温馨顿时涌上心头。


本文要讲述的也是一个颇有中国特色的网络技术,其实很多人都遇到过,但没有去深究。最早向我反馈的是一位细心的网友,他在打开www.17g.com这个游戏网站时,有一定概率会加载出其他网站的游戏,比如xunlei的。他觉得很好奇,便采取了一些措施来排查。


  1. 一开始怀疑是电脑中毒,于是在同网络下的其他电脑上测试,症状还是一样。

  2. 其他地区的网友(包括我)打开这个网站时没有发现相同问题。

  3. 他怀疑是当地运营商(哪家运营商我就不说了)搞的鬼,于是换了个宽带,果然就没问题了。


这位网友很生气,想知道运营商究竟对他的网络做了什么手脚,所以抓了个出问题时的包来找我。我刚开始以为很简单,肯定是运营商的DNS劫持,即故意在收到DNS查询时回应一个假的IP地址,从而导致客户端加载错误的广告页面。于是我打开网络包,用dns作了过滤,发现www.17g.com被解析到了IP地址123.125.29.243(它还有一个别名叫w3.dpool.sina.com.cn,见图1)。可是经过进一步测试验证,发现这个IP地址竟然是对的,并没有被劫持。


1



既然不是DNS劫持,那又是什么原因导致的呢?可惜这位网友抓包的时候电脑上开了太多应用,所以干扰包很多,无法采用暴力方式来分析(就是指不过滤,用肉眼把所有包都一一看过的分析方式)。如果用“ip.addr eq 123.125.29.243”过滤则得到图2的结果,似乎平淡无奇,只是显示有些包乱序了,但不知道这意味着什么。后来我才知道这就是线索之一,具体原因后面会讲到。


2



由于这是我第一次分析劫持包,所以不得要领,当晚分析到凌晨都没有弄明白。第二天早上只好到技术群求援了,一位在运营商工作的朋友给我科普了HTTP劫持的几种方式。其中有一种引起了我的注意,其大概工作方式如图3所示,实线箭头表示正常的网络包,虚线箭头表示运营商做的手脚。


3


注意:这只是简单的示意图,不完全等同于真实过程。


在正常情况下,用户发出的HTTP请求(即图中的①)经过层层路由才能到达真实的Web服务器,然后真实的HTTP响应(即图中的③)又经过层层路由才能回到用户端。而在做了手脚的网络中,运营商可以在路由器上复制HTTP请求,再交给假的Web服务器。然后赶在真实的HTTP响应之前,把假的HTTP响应(即图中的②)送达用户。这个抢先应答会导致用户在收到真实的HTTP响应时,以为是无效包而丢弃。


根据这个工作原理,我们能否推测出假的HTTP响应有什么特征呢?如果能,那就能据此过滤出关键包了。我首先考虑到的是网络层的特征:因为假Web服务器是抢先应答的,所以它发出的包到达用户时,TTL(Time to Live)可能和真实的包不一样。那要怎么知道真实的TTL应该是多少呢?考虑到3次握手发生在HTTP劫持之前,所以我们可以假定参与3次握手的那台服务器是真的,从图4可见其TTL为54。


4



接下来就要动手过滤出假的包了。根据其源地址同样为123.125.29.243,但TTL不等于54的特征,我用“(ip.srceq 123.125.29.243) && !(ip.ttl == 54)”过滤,得到图5的两个包,即8号包和9号包。看看右下角显示了什么信息?这不正是我要寻找的假页面“src=http://jump.niu.xunlei.com:8080/6zma2a”吗?


5

 

这个发现令我信心大增,有种拨云见日的感觉。再往下看几个包,果然发现了和jump.niu.xunlei.com的新连接。接着这个连接又把页面跳转到了“http://niu.xunlei.com/actives/welcome1426……”上(见图6)。跳来跳去地非常难以追寻。


6

 

再后面的包就没必要分析了,以上证据已经足以向工信部投诉。据说投诉后运营商解决起问题来还挺爽快的,百度曾经上诉某运营商的劫持案件也获赔了。商场上的黑暗故事,就不在本书里展开讨论了,我们还是继续关注技术问题吧。


在这个案例中,万一真假网络包的TTL恰好一样,还有什么办法可以找出假的包吗?仔细想想还是有的。比如服务器每发送一个包,就会对其网络层的Identification作加1递增。由于4号包的Identification为4078(见图7),那它的下一个包,也就是8号包的Identification就大概是4079了(或者略大一些)。可是从图8可见,它的Identification一下子跳到了55872,这也是一个被劫持的明显的特征。


图7



图8

 

那万一运营商技术高超,把TTL和Identification都给对上号了,我们还有什么特征可以找吗?还是有的!刚刚介绍的两个特征都在网络层,接下来我们可以到TCP层找找。在图5可以看到8号和9号这两个假冒的包都声明了“win=2102400”,表示服务器的接收窗口是2102400字节。对比一下其他网络包,你会发现这个数字大得出奇。为什么会这样呢?这是因为真正的Web服务器在和客户端建立3次握手时,约好了它所声明的接收窗口要乘以128(见图9)才是真正的窗口大小。假的那台服务器不知道这个约定,所以直接把真正的窗口值(win=16425)发出来,被这么一乘就变成了16425×128=2102400字节,大得夸张。


图9



这个特征在本案例中非常明显,但不是每个TCP连接被劫持后都会表现出来的。假如3次握手时没有声明图9所示的Window Scale值,那就无此特征了。

其实我在一开始还提到了另一个现象,即图2中Wireshark提示的[TCP Previous segment not captured]和[TCP Out-of-Order],意味着存在乱序。为什么会有这些提示呢?这是因为假服务器伪造的包抢先到达,增加了Seq号,因此等到真服务器发出的包到达时,Seq号已经对不上了。Wireshark还没有智能到能判断真假包的程度,只能根据Seq号的大小提示乱序了。


总而言之,在理解了劫持原理之后,我们便能推理出假包的特征,然后再根据这些特征过滤出关键包。但不是所有特征都能在每次劫持中体现出来的,比如接收窗口的大小就很可能是正常的,所以一定要逐层认真分析。这还只是众多劫持方式中的一种,如果采用了其他方式,那么在包里看到的现象又会有所不同。等我下次遇到了,再写一篇跟大家分享。


作者信息:

林沛满

林沛满是一位有近十年存储经验的技术专家,擅长文件存储的性能分析、归档和备份。同时也专注于网络协议分析,比如CIFS/NFS/HTTP/TCP/UDP等,是《Wireshark网络分析就这么简单》、《Wireshark网络分析的艺术》等书的作者。

 

注:本《大咖讲网络》系列文章取自《Wireshark网络分析的艺术》一书。




其它参考文章:

【大咖讲网络】系列文章倾情奉献!



更多精彩内容,请点击阅读原文”进行查看!

如何每天都能收到如此精彩的文章?

①点击右上角点击查看官方账号”→点击关注

②长按并识别下图中的二维码,直接访问EMC中文支持论坛


 
戴尔易安信技术支持 更多文章 私有云投资回报率:压低运营成本 揭秘Pivotal:你我身边最熟悉的陌生人,其实是富二代技术大牛! 企业集成平台在合并后第一天就实现了关键业务的交叉可见性 上月热点汇总! 虚拟磁带库(VTL)简介
猜您喜欢 杭州要建未来图书馆?由你来设计创造! flume应该思考的问题 【译】S.O.L.I.D 原则在 Go 中的应用(上) 平安金融壹账通测试技术周报(第四十七期) 从大数据获益最多的7个产业