一、劫持的方式分析

互联网的流量劫持大致分两种,第一种是DNS劫持,第二种是链路劫持。对于这两种劫持的原因有很多,比如用户电脑中毒了,DNS被篡改了,比如家用路由器被攻破了等等。但这种个人极端原因毕竟是少数,真正的幕后大佬(此处应该有广东话配音)其实是运X商(此处配有BB音),这其实已经是互联网行业公开的秘密,各大互联网公司早已经和各大运营商展开了一场旷日持久的撕胯大战,po主公司由于是金融行业,刚涉足互联网不久,还处于摸石头过河阶段,却也是感受到了我国互联网环境的水深。对此po主只有一句话,大家都是要被颠覆的行业,难兄难弟何必相爱相杀呢? 好了,废话不多说了,这是一个严肃的技术文档!!!

1、DNS劫持

首先我们要搞明白运营商为什么要劫持用户DNS呢?  用户跟你什么仇什么怨?

劫持原因基本分两类,第一类是为了跳转广告,第二类是本地缓存,总结一下就是为了——钱!

跳转广告比较好理解,我明明访问的是淘宝,怎么跳转成了一个不知名小网购网站,还和淘宝长的挺像。本来po是要以身试法,截个被劫持的图下来展示下的,结果访问各大网站1个小时,也没有一次被劫持,真心为电信点赞! 跳转广告这种方式由于过于芳草天,用户也不是傻子,运营商用起来也是比较谨慎,所以第二类本地缓存才是罪恶之源。

由于各运营商带宽资源、网间结算费用、IDC机房资源分布等存在较大差异,因此为了保证网内用户的访问质量,同时减少跨网结算,运营商在网内搭建了内容缓存服务器,通过把域名强行指向内容缓存服务器的IP地址,就实现了把本地本网流量完全留在了本地的目的。但是由于运营商对这些内容缓存服务器的使用的技术手段参差不齐,运维管理也不是很及时。通常会引起两个问题,一是当这些运营商的内容缓存服务器出现故障后,用户将无法访问到需要的资源,二是当源站已经有内容更新了,而这些运营商的内容缓存服务器并未及时更新,导致用户访问到旧资源,或者无法访问到资源。

其实运营商的DNS劫持的原理很简单,就是当用户向local DNS去请求某个域名的真实ip时,运营商的local DNS服务器回复了一个假网站或内容缓存服务器的ip,最终导致用户访问出现异常。当然一些劫持行为一旦被发现,运营商一般都会声称DNS服务器被黑,当然也可能声称临时工干的。DNS劫持由于其实现简单,无论是出于有意或无意的,目前被广泛的应用在互联网环境中。根据腾讯内部的统计,腾讯全国每日的DNS解析异常量达到80万条,并且这还只是一个抽样监测的结果。这对于企业的影响是非常恶劣,尤其在移动互联网时代,用户体验就是核心竞争力,因此DNS劫持的攻防之战也是一个互联网公司必须重视的课题。

2、链路劫持

      比起DNS劫持的简单粗暴,链路劫持的技术含量更高,也更难被发现。最常见的就是页面蒙层,页面广告,页面替换等(这里的页面替换不同于DNS劫持,即使更换了local DNS依然会被劫持,所以更难察觉)。当然链路劫持还常常被黑客利用进行钓鱼或DDOS攻击等(近期比较有名的就是某邪恶组织利用百度联盟广告被恶意植入JS去DDOS攻击GitHub)。我们这里就不多谈个别极端情况,具体的黑客行为可以参考这篇文章《详解流量劫持的形成原因》

链路劫持的原理就是运营商(也可能是黑客)在用户访问网站的时候进行窃听,获取用户访问的目的ip后,然后以这个ip为source-ip冒充网站给用户响应,通常响应中会插入一段JS代码,这段代码可能会让用户去get一些非真实网站资源,最终可能造成真实页面被插入广告,被蒙层,甚至整页面被替换,严重影响用户体验以及企业形象。由于链路劫持可能通常发生在last-mile,而last-mile被运营商牢牢控住,所以这对监测以及解决问题带来了巨大的挑战。

二、可选的解决方案

        针对于DNS劫持和链路劫持,业界有比较多的解决方案,各有利弊,适合不同的场景,总体上来说可以分两大类,一是被动监测型,二是主动防御型,下面就分别介绍一下。

1、被动监测型

被动监测型主要是通过采集用户访问站点的网络参数的方式来判断是否遭到劫持,比如通过采集用户访问站点的ip地址来和我们真实站点以及CDN节点的ip地址进行比对,判断是否遭到DNS劫持,或者通过采集用户访问的URL和真实站点的URL进行比对,判断是否遭到链路劫持。在PC时代对于被动监测型一般就是真机模拟这一种方式,但是在随着移动互联网的快速发展,针对于移动APP出现了一种插入SDK来监测的方式,这两种方式采用的技术手段完全不同,也各有利弊。

   1)真机模拟型

由第三方监测厂商提供全国范围内的监测服务,通过真实的PC或手机模拟用户的真实访问来收集相关 的性能参数,然后由厂商对数据进行分析,最终为客户呈现性能指标或者提供告警服务。

优点:1、落地容易、实现简单;

2、不用修改任何APP的代码,和原程序完成无耦合。

缺点:1、手机真机的模拟,由于手机成本以及移动流量的原因,数量比较有限,采样数据的覆盖度较低。

    2)插入SDK型

主要用于移动APP,通过在移动APP中插入SDK的方式,收集用户访问站点的性能参数,并将其统一发送至数据分析平台,最终呈现出性能指标以及相关告警服务。目前市场上有多家APM厂商提供类似的服务,实现方式一般分为SaaS以及私有云两种,对于一般小企业考虑到成本问题会选择SaaS模式,相关性能数据统一发送到APM厂商的公有云上,厂商加以分析,最终呈现的结果客户可以通过web方式查看。而对比注重安全的大企业,无法接受数据被上传到第三方的云端,部分APM厂商也会提供相应的私有云解决方案。

优点:1、数据来自真实用户,具体更高的真实性和完整性。

缺点:1、SaaS解决方案安全问题

2、私有云解决方案成本高,部署复杂

目前被动监测的方式多为购买第三方厂商的监测服务,在发现某一地区的劫持率超过阀值后会向企业告警,企业依据厂商提供的证据向运营商投诉,但是往往运营商的处理效率非常低,因此要从根本上解决问题,需要采取一些主动防御的解决方案。

2、主动防御型

主动防御型就是主动出击从根本上杜绝劫持的可能,对于DNS劫持的解决思路目前po主了解的主要有两种,第一种是绕过运营商的local DNS,使用公共的DNS,另一种是直接通过ip来访问,抛弃了域名访问的模式。而对于链路劫持,业内目前还没有什么太好的主动防御模式,https应该算一种,但是https也会带来诸多其他问题。下面分别介绍下几种思路。

1)绕过运营商localDNS,使用公共的DNS

让用户不使用运营商的local DNS改用114DNS,114DNS是国内最大的中立缓存DNS。推动用户自己手工去改DNS显然是不可行的,用户10个有9个都不知道DNS是啥。那如何去让用户不使用运营商的local DNS呢?po主在腾讯的一个工程师的博客里面看到有这么一段话:“如何在用户侧构造域名请求:对于PC端的客户端来说,构造一个标准的DNS请求包并不算什么难事。但在移动端要向一个指定的LocalDNS上发送标准的DNS请求包,而且要兼容各种iOS和Android的版本的话,技术上是可行的,只是兼容的成本会很高。”po主认为这种方式暂且不谈技术上是否可行,最大的问题应该是无法确保公共DNS的稳定性。一旦公共的DNS遭到攻击,将会导致全国性的故障,所以一定需要一个冗余的方案,就是当公共DNS挂了后,可以去向运营商的local dns去请求。

2)抛弃域名访问方式,直接进行通过IP访问

这种解决思路,po主了解的有两种方式,第一种是httpdns,这种应该是目前DNS防劫持的主流方式,但是网上相关的介绍非常少,从腾讯员工的博客以及阿里朋友给的内部资料上看,现在腾讯和阿里都在用这种方式。另一种是网宿的MAA解决方案。两者的原理大同小异,都是为移动APP而量身定制的。

httpdns的原理大致就是在移动客户端中加入一个域名解析的模块,客户端通过http的方式向企业的流量调度服务器请求ip,此时流量调度服务器会回根据用户所在位置给用户一个最优的ip。客户端在获取ip后直接用此ip来访问所需站点资源。

这种方式看着确实很完美,但是对于一般的企业来说想要实现是一件极具挑战的事情。

1、客户端需要进行一定的开发来满足客户端的httpdns的请求;

2、针对这个流量调度服务器需要自己开发一套所有节点的IP地址库以及测速系统,才可以保证将用户引导的访问最快的IDC节点上,并且对于使用了CDN加速的域名来说,这个IP地址库是不可控的。

3、如何保证高可用性以及不同运营商的用户访问到同一个HttpDNS的服务IP,用户的访问延迟?腾讯的做法是:HttpDNS通过接入了腾讯公网交换平台的BGP Anycast网络,与全国多个主流运营商建立了BGP互联,保证了这些运营商的用户能够快速地访问到HttpDNS服务;另外HttpDNS在多个数据中心进行了部署,任意一个节点发生故障时均能无缝切换到备份节点,保证用户解析正常。

所以说httpdns是一个好的解决方案,但是用起来并不容易,而其投入产出比也只有在一些巨型的互联网公司身上才能体现出来。

再来说说网宿的MAA的解决方案,po主觉得和httpdns比较类似,前提是这个域名要使用网宿的CDN加速。网宿的MAA方案其实就是帮一般企业来解决上面httpdns的三点难点。

1、客户端插入网宿研发的SDK,向其鉴权服务器请求ip;

2、网宿的鉴权服务器类似于httpdns中的流量调度服务器,因为CDN厂商本来就要负责调度CDN节点的资源,所以这点对他们来说很容易;

3、如何保证高可用性以及不同运营商的用户访问到鉴权的服务器,用户的访问延迟?这点网宿的资料里面没有提到,po主个人猜测问题应该不大,因为对于一个CDN加速的域名来说,用户本来就是要去网宿的鉴权的服务器的,而对于一个提供CDN服务的厂商来说,鉴权的服务器的高可用肯定是要做好的。

(以上绝对非软文,po主觉得是个很好的解决思路,表示要向网宿征收广告费啊!!!)

但是网宿的这个解决方案同样存在问题:

1、插入SDK的方式很多大企业可能无法接受

2、只能用于网宿加速的域名,其他厂商的CDN节点的ip信息网宿不可控,这样可能会被一个厂商绑架。

3)https

注意https是解决链路劫持的方案,并无法解决DNS劫持的问题。https的优点太多了,什么保密性、完整性、可用性,我就不多说了,去网上一搜一大堆,我这里就只谈谈如何防御链路劫持。

1、https是加密协议,我们随便抓个http包,发现http包里面的所有东西都是明文的,这样就会被监听,而https协议是加密的。

2、但是光加密还不够,因为只是application data被加密了,网络层的信息都没有被加密,邪恶势力依然可以用数据包的目的ip作为源ip响应用户。https还有另一大特点是要验证数字证书,为了确保客户端访问的网站是经过CA验证的可信任的网站。所以这就几乎彻底杜绝了链路劫持的可能。

但是https也不是如此完美,虽然https解决了诸多安全问题,但是对性能也有着比较大的影响。一是用户要从http跳转到https,并且要多几次TLS的握手,这会消耗一定的时间;二是服务器的压力也会增加。除此之外如果使用全站的https,所有页面里面的嵌入资源都要改成https,APP的程序也要进行相应的修改,CDN的所有节点也必须都支持https并且导入证书。所以全站https并不是一件容易的事情,国外的Google、Facebook、Twitter早已支持全站https,但目前国内大多数公司都没有采用全站https的方式,微信算是一个,前段时间百度表示已经支持全站的https了,前段时间我试了一下,百度主站在pc端和移动端都已经可以自动跳转到https了,但是近期发现移动端又恢复成http了,可能是考虑访问体验问题。由此可见全站https应该是未来互联网的趋势。

三、选取何种解决方案

(以下仅代表个人观点)

   1、主动防御型的解决方案总体上看虽然可以从根本上解决劫持问题,但是成本高,研发周期长,适合超大的互联网公司,但未必适合所有企业。

2、被动监测型中,真机监测显然不是未来主流发展方向,并且覆盖范围小是硬伤,但是安全无副作用。

SaaS方式的插SDK具有一定的安全风险,在传统行业尤其是金融行业中很难被接受。

私有云方式的插SDK成本比较高,部署相对复杂。

那么问题来了,又便宜又安全又好用的东西,你告诉我一个我去批发来卖。

3、能否自研制SDK。这个问题要问开发,我个人理解应该是可以。但是抓取了海量的数据要自己去分析并不是一件容易的事情,需要花费很多的人力物力,毕竟这种第三方监测厂商百来号人就是靠这个吃饭。厂商卖的不是一个简单的SDK,卖的是服务。说到底还是一个投入产出比的问题,是自己花精力去搞但未必成功,还是买一个现成的商业解决方案。

4、被动监测型除了监测劫持问题外,还有很多其他功能。比如CDN的服务质量评估,比如用户访问的网络性能分析,甚至可以追踪到移动应用的崩溃原因以及代码级别的执行时间开销。这对于提高用户体验,减轻运维压力都是及其重要的。

关于互联网流量劫持分析及可选的解决方案相关推荐

  1. 互联网流量劫持的背后:黑客月入至少三万

    明明打开的是A网站,莫名其妙却被跳转至B网站:明明想下的是A软件,下载安装后却是B软件:打开一个App,弹出的广告让人心乱如麻,同时也不胜其烦--你以为电脑手机中毒了?错!或许你真的错怪了病毒,因为你 ...

  2. 传输协议不安全,数据泄露谁之过?——流量劫持技术分析

    万物互联时代,无线网络全面覆盖我们的生活,基本上各家门店都有wifi标志,而且有的还没有密码,蹭WiFi似乎已成为一项基本"生存技能",现代人的基本状态就像下面这首打油诗一样: 枯 ...

  3. 运营商 html劫持 原理,域名劫持、运营商流量劫持的现象及分析

    1.域名劫持 现象就是,打开网站的页面,会出现莫名的跳转到站内或站外其他的网址.或者直接显示了站外的内容. 判断方法,更换其他绑定您网站的域名来访问,看是否正常.如果其他域名访问正常,应该基本确定是被 ...

  4. Web如何应对流量劫持?

    虽然互联网经过多年的发展,可是网站使用的底层协议仍是 HTTP,HTTP 作为一种明文传播协议,所有的传输数据都是明文,我们都知道在通信中使用明文(不加密) 内容可能会被窃听,同时网站存在被劫持的风险 ...

  5. Istio 中的 Sidecar 注入及透明流量劫持过程详解

    图片来源:上海五角场 by Jimmy Song 本文基于 Istio 1.5.1 版本,将为大家介绍以下内容: 什么是 sidecar 模式和它的优势在哪里. Istio 中是如何做 sidecar ...

  6. 爱测未来安全-浅淡流量劫持及应对措施

    在前几天公司里的某个项目组产品遇到了一件怪事,且听我重现下过程和场景(来自用户反馈的还原). A用户:这产品真不错,同事刚刚推荐的,那我得赶紧用用...启动中...嗯?怎么插入了这么一个大广告,不会吧 ...

  7. 《网络安全应急响应技术实战指南》知识点总结(第10章 流量劫持网络安全应急响应)

    一.流量劫持概述 1.流量劫持简介 是一种通过在应用系统中植入恶意代码.在网络中部署恶意设备.使用恶意软件等手段,控制客户端与服务端之间的流量通信.篡改流量数据或改变流量走向,造成非预期行为的网络攻击 ...

  8. 流量都去哪了? --- 详谈流量劫持是如何产生的?

    流量劫持是如何产生的? 原文出处:FEX 做最专业的前端[百度前端团队Blog] 原文链接:http://fex.baidu.com/blog/2014/04/traffic-hijack/ 流量劫持 ...

  9. 安全科普:流量劫持的方式和途径

    流量劫持,这种古老的攻击沉寂了一段时间后,最近又开始闹的沸沸扬扬.众多知名品牌的路由器相继爆出存在安全漏洞,引来国内媒体纷纷报道.只要用户没改默认密码,打开一个网页甚至帖子,路由器配置就会被暗中修改. ...

最新文章

  1. 图像点云数据融合方法汇总
  2. 相似度和相异度、常用距离度量、余弦相似度
  3. 消息通信库ZeroMQ 4.0.4安装指南
  4. 多线程并发神器--ThreadLocal
  5. 这可能是史上最全 Redis 高可用解决方案总结
  6. 第十五章,读取txt文件(C++)
  7. java 一个数组key一个数组value_在各种语言中,使用key在map中获取value 和 使用下标获取数组中的数据 相比哪个更快?...
  8. SCRUM 系列之一 ----- 认识SRCUM
  9. 基于IMAP的邮件收发系统
  10. 解决android.view.AbsSavedState$1 cannot be cast to android.widget.CompoundButton$SavedState
  11. 人工智能与安全论坛:智能与安全的融合与对抗
  12. 10.第十一章.风险管理
  13. pe系统怎么安装linux系统教程,U盘安装windows+ubuntu+winpe三系统详细教程
  14. 汽车驾驶 - 侧方停车
  15. 数据库实验2:简易登录页面设计(c#)
  16. 将英汉词典数据库放入MySQL数据库中,并将数据库中“以A开头的单词”显示在JSP网页上
  17. xml文件中的红叉号问题
  18. Git 无法切换分支,报错git did not exit cleanly
  19. 【IPAM】Netbox docker模式版本升级
  20. JS实现常见文件类型的下载/保存

热门文章

  1. 无限超越超级机器人nds_无限边境超级机器人大战OG传说超越隐藏宝箱
  2. libtorch opecv c++ cmake clion
  3. java 内存 监控_Java内存监视
  4. 苹果手机语音备忘录在哪_苹果手机的录音功能在哪?教你快速开启,想录音太方便了...
  5. 30道面试常见的数据结构算法题
  6. C++function,future,packaged_task
  7. js php活动倒计时,JS活动倒计时代码
  8. 对话Digital FUN和TEA社区创始人Totti#MiXTalk004
  9. vivo 提前批图像算法工程师(AI方向)一面+hr面
  10. 我的十年 谨以此文迎接我即将到来的三十而立