DNS、HTTP劫持的一些事

1、什么是DNS劫持？

DNS劫持就是通过劫持了DNS服务器，通过某些手段取得某域名的解析记录控制权，进而修改此域名的解析结果，导致对该域名的访问由原IP地址转入到修改后的指定IP，其结果就是对特定的网址不能访问或访问的是假网址，从而实现窃取资料或者破坏原有正常服务的目的。DNS劫持通过篡改DNS服务器上的数据返回给用户一个错误的查询结果来实现的。
DNS劫持症状：在某些地区的用户在成功连接宽带后，首次打开任何页面都指向ISP提供的“电信互联星空”、“网通黄页广告”等内容页面。还有就是曾经出现过用户访问Google域名的时候出现了百度的网站。这些都属于DNS劫持。
再说简单点，当你输入google.com这个网址的时候，你看到的网站却是百度的首页。

网站劫持检测DNS污染检测

2、什么是HTTP劫持？

在用户的客户端与其要访问的服务器经过网络协议协调后，二者之间建立了一条专用的数据通道，用户端程序在系统中开放指定网络端口用于接收数据报文，服务器端将全部数据按指定网络协议规则进行分解打包，形成连续数据报文。
用户端接收到全部报文后，按照协议标准来解包组合获得完整的网络数据。其中传输过程中的每一个数据包都有特定的标签，表示其来源、携带的数据属性以及要到何处，所有的数据包经过网络路径中ISP的路由器传输接力后，最终到达目的地，也就是客户端。
HTTP劫持是在使用者与其目的网络服务所建立的专用数据通道中，监视特定数据信息，提示当满足设定的条件时，就会在正常的数据流中插入精心设计的网络数据报文，目的是让用户端程序解释“错误”的数据，并以弹出新窗口的形式在使用者界面展示宣传性广告或者直接显示某网站的内容。

3、如何判定是DNS劫持还是HTTP劫持？
从个人遭受DNS和HTTP劫持情况来看，DNS劫持多倾向展示广告（网页出现错误后跳转某些网页，如带有运营商名号的114，189等网页），恶意插入产品的推广，如针对特定设备的推广，apple设备的app推广，某些开发者利用了apple开发者协议这个口子进行的恶意app推广。
本人的这次DNS劫持的手段相当恶略，其在劫持的网页中注入了恶意脚本木马。（在PC端修改UA访问该网站，Bitdefender不断的拦截到恶意脚本）

强行推送广告（非原网页的广告）
DNS劫持倾向于持续性，访问被劫持的网站时，会不停的出现其恶意广告。
HTTP劫持，这种劫持也是最为麻烦，其常见的现象为针对大流量网站的加小尾巴行为，如百度，hao123导航，360导航，百度知道，各大电商网站（淘宝，天猫，当当等）
HTTP的劫持出现的频率多变，针对不同的ip也会不同(断网之后再连接，也许劫持就暂时消失），一定程度会造成错误的假象，用户可能会忽视该问题，由于其劫持过程非常快，只是经过某个IP后就快速的跳转，用户如果不注意地址栏的变化，根本不会注意到该问题的出现。

----------------------------------------------------------------------------------------------------------------------------
DNS劫持判断，更改DNS，改成如114DNS，阿里DNS，onedns等，然后访问同样的网页，之后没出现类似的问题，即可判定为DNS劫持，DNS的解决不困难，手动换DNS，或者是投诉奸商（效果不理想，我投诉后不到一个星期，劫持再现）
HTTP的劫持，判定就困难多了，首先需要排除干扰，如hosts是否干净，是否有恶意软件，恶意插件，系统是否中病毒等（还有盗版系统），但是如果有iphone或者是ipad（不越狱），这就比较容易排除干扰项。首先需要注意的是各类的国产软件的也会造成后面的小尾巴，用户很容易就错误判断为运营商劫持。（各类浏览器插件，小心）
关于HTTP的劫持的解决方法，目前没有切实可行的方法可以解决该问题，除了向工信部投诉，然后等待奸商妥协（不要直接向运营商投诉，劫持问题的发生地很可能是跨地域的，用月光博客的话说就是“某台特殊的设备躺在线路上，对经过的http随机性投毒”，本地运营商极有可能没有权限，也没有技术去解决，或者是演变成为各级别运营商之间的相互推诿）
目前比较可行的方法是，访问https加密，这个百度（劫持的重点对象）已经动手了，强制http跳转https，但其他网站就别想了。（V-P-N，也ok）{强烈建议不要使用hao123,360导航，2345导航，毒霸导航这类网站}
折衷的方法，就是将劫持的IP添加到防火墙上（不是hosts），但是劫持依旧，这是劫持者无法获利，麻烦的是添加防火墙后，劫持等待跳转的时间比被彻底劫持花费的时间更长。

360导航的劫持IP被阻止后，第一次甚至无法打开360导航
这就是我捕获的劫持IP（针对百度，hao123,360导航，百度知道）Fiddler的成果，添加防火墙后，过一段时间新的劫持ip又会出现

[CSS] 纯文本查看 / 双击代码区域 Ctrl+A快速复制

01 02 03 04 05 06 07 08 09 10 11 12

182.92.105.41 #360导航新 北京阿里巴巴 182.92.105.41 120.24.232.226 #深圳阿里巴巴 123.56.42.120 #杭州阿里巴巴 123.56.42.120 115.29.52.50 #杭州阿里巴巴 120.24.231.137 #深圳阿里巴巴 182.92.77.59 #北京阿里巴巴 182.92.150.103 #北京阿里巴巴 123.57.40.77 #杭州阿里巴巴 114.215.128.157 #青岛阿里巴巴 42.96.248.55 #北京阿里巴巴

（下文会提到为什么都指向阿里巴巴的服务器上了）
--------------------------------------------------------------------------------------------------------------华丽分割线
以下是一篇关于HTTP劫持的详细技术解析（http://blog.csdn.net/wr410/article/details/25594273）

ISP的劫持手段真是花样百出，从以前的DNS(污染)劫持到后来的共享检测，无不通过劫持正常的请求来达到他们的目的。
之前分析过通过劫持HTTP会话，插入iframe来检测用户后端有无共享行为，但后来移动终端的发展导致ISP开始有所收敛，因为即使检测出来也不敢断用户的网了。
可是现在又出了新的花样……
最近，每当我打开baidu首页的时候，总是发现奇怪的现象，明明输入的只是www.baidu.com，但是却莫名其妙的出现了跳转，最后发现实际访问的URL竟然带上了尾巴。
好吧，起初我以为我又被流氓软件盯上了，但左思右索使劲翻遍也没发现什么被弓虽女干的迹象，只好打开虚拟机来试试，结果发现我干净的虚拟机也出现了一样的现象。
这时我才明白，又被电信劫持了，那么这次又是怎样的劫持手段呢？
-----------------------------------------------------------------------------------------------华丽分割线
被劫持的现象
首先，我们看看现象：

当我们打开www.baidu.com的时候，浏览器最终的目的URL却变成了http://www.baidu.com/?tn=90509114_hao_pg
这中间明显感受到了页面的跳转，那么我们看看浏览器上的后退按钮，就发现了端倪。
http://112.124.105.244/jmp?m=redirect&src=szdx-baidu
咦，这是什么地址，看起来就像劫持的玩意，再仔细一看，szdx（深圳电信），真是自报家门，毫不忌讳啊！
劫持的原理
那么电信是如何劫持了我们正常的百度请求呢？

经过检查，DNS是正常的，没有问题，那就说明这是HTTP链路层劫持了。
果断抓包，进行一次被劫持的会话，很快就有了。

咋一看，请求的服务器IP没有错，似乎没什么问题，但仔细一看问题就有了。

内容完全就不是一回事，这玩意怎么可能是百度返回的嘛，显然是被赤裸裸的劫持了。
继续深挖扩线，看看究竟在哪被劫持了。
先看看正常的百度响应。

唔，人家的服务器可是BWS（BaiduWebServer）呢！
那么就说明，我的HTTP会话被劫持了，收到了伪造的响应，回头再从被劫持的TCP流中寻找痕迹。

没错，我们找到了这个相当关键的细节！
我们在收到伪造的响应后，又收到了一个被认定为“伪造的重响应”数据包，而这个数据包正是我们这次请求真正的响应。
但此时，这个数据包已经视为无效了，观察SEQ和ACK编号即可发现其手段（TCP原理，请参考RFC#3708）。
为了证实这个是伪造的响应，我们知道一个人可以伪装成任何样子，但是其指纹可不是随便就能改变的。
HTTP工作在应用层，应用层就是一个人的外貌，想换成什么样子都行，但是IP层（网络层）所在的操作系统可就是指纹了。
我们先看看我这到正常百度服务器的IP包TTL值为54，这是一般不会改变的，即使路由不同，其波动也不过±1、2

然后再看看被劫持的响应IP包TTL值竟然为252，这就证明了不仅被非法劫持了而且这黑手离我仅几步之遥！
科普：不同的操作系统环境TTL值一般是固定的一个数，常见的是16的倍数，然后每经过一个节点减1。

顺水推舟，揪出元凶。先看看我这到百度服务器经过了哪些网络节点。

嗯，然后我们ping一下百度服务器，确认其TTL为54，与上述一致。

然后我们ping一下3号节点，TTL值为253，没有问题。

接着我们ping下一个5号节点，TTL值为251，也没有问题。
那么TTL为252的4号节点，显然就是劫持我们的元凶了，可是人家早就不让ping了，呵呵。
根据电信的网络结构，2、3号节点算是DSLAM接入、汇聚层集，那么4号节点显然是在城际骨干网前面插入类IDS系统的节点了。

由此证据链已经完整，我们可以得出一个结论：HTTP劫持就是ISP所为。
----------------------------------------------------------------------------------------------------华丽分割线
劫持的动机
事物的存在肯定有其必然性，既然现在不检测共享了，那么为什么要劫持咱们的百度请求呢？
业内人士都应该知道，百度和hao123这类网站都有联盟存在，联盟的作用就是推广，带来流量。
加尾巴的行为，就是在做这种事情。
就深圳的居民用户数来说，按一天100W的保守访问计数来说，假设100元/W访问付费，那么一天下来，ISP就有了1W元的收入，那一个月就有30W的额外收入了。
假如通过这种方式，劫持各种购物网站，加入自己的推广，按一天成交额100W，平均返利1%计算，这又是一天1W元的收入，那一个月又有30W的额外收入了。
所以这种仅仅只需要对HTTP请求的host参数判别进行劫持就可以坐着收钱的事，谁都何乐而不为呢？
记住上面只是保守计算的例子而已，谁知道将来还有其他的什么东西？
至于这个行为是ISP的行为还可以理解，但如果是某些员工的个人行为私自牟利那我认为这就玩大了，但无论是哪种，粗暴侵犯用户通信自由，都是违法行为！
建议出现这种现象的用户，果断向ISP，必要时可找工信部。
-----------------------------------------------------------------------------------------------------华丽分割线
坚强的后盾
好像遗漏了一点，112.124.105.244这是何方神圣，为何能承载深圳电信数以万计的请求量？
inetnum: 112.124.0.0 - 112.124.255.255  
02.netname: ALIBABA-CN-NET  
这个IP来自杭州，查询IP信息发现，原来是阿里云的服务器。
加之这个服务器只是跳转功能，用的是ATS（Apache Traffic Server）服务器，所以区区几百万的小流量还真不算什么。
为了尽可能的让用户感受不到被劫持，保证速度是关键，看得出人家选择阿里云也是用心良苦啊！
-----------------------------------------------------------------------------------------华丽丽分割线
向劫持说不
那么我们怎么防范劫持呢？ 
很遗憾，还真没办法预防。
唯一可行的预防方法就是尽量使用HTTPS协议访问。
目前，我们知道其劫持原理后知道只能通过检测TTL的变化或HTML元素检查来判定，但这都不是一般用户可以解决的。
不过，根据目前的情况，我们可以考虑在边界设备针对TTL为252且为TCP协议的包做DROP处理，切记不能REJECT。
（以普通居民用户的网络来说，TTL为252的TCP响应几乎不可能存在，所以特异性还是比较突出的）
但治标不如治本，还是去投诉吧！

更新：

现在运营商的劫持又多了新花样了，原来可以依靠hosts或者防火墙屏蔽特定的站点或ip可以缓解劫持，但是现在运营商又有新招了，针对百度的劫持可以免跳转特定ip来实现。
如果用户从http://www.baidu.com访问百度，最后跳转https://www.baidu.com时依然会被加小尾巴，或者是用户从非https的百度的其他站点，如：news.baidu.com跳转https://www.baidu.com时，同样可以被加小尾巴，而不需要转到特定的ip来实现劫持。


用户还需注意下载文件（就算是该文件的官网），用户下载到的文件也有可能是运营商的CDN服务器的缓存文件或者是“加料”文件，用户需要注意文件签名的更新时间和校检文件md5