段海新：谢谢陈教授的介绍，也谢谢主办方的邀请，让我今天能够有机会和大家分享一下我最近的一些研究成果，感觉到非常高兴。

CDN现在已经成为互联网的一些基础设施，和所谓实证研究，也就是说我们其实这几年的研究基本上也都是研究现实已经部署的这些CDN系统可能存在的一些问题，以及一些防范措施。所以我们的研究很少是从理论方面，主要是看我们的论文，基本上都是一些实验和数据。

现在说CDN已经成为互联网的基础设施，一个是来源于Akamai，还有就是从中国工信部的一些数据统计。我们知道世界上一些主流的应用，基于Web的应用基本上都不属于CDN，Akamai是世界上用户最多的CDN的厂商，他一个公司承载了15%到30%的Web流量。我们工信部的统计里面说，排名前100%的网站有91%是使用CDN，包括这些知名的企业。有一些公司，像互联网公司，包括亚马逊、百度、腾讯这些公司，虽然没用第三方的CDN，基本上也是用的CDN的技术。

我们看一下CDN基本的功能，可以说几个方面。首先是分担负载，其次是降低延迟，提高用户的体验。然后过滤一些攻击，比如可以用Wap防火墙过滤，包括抗Dos，CDN也是抗Dos攻击标准的防范措施。它的工作原理，用户在访问这个原始网站的时候，首先是向服务器发一个请求，比如你要访问a.com的时候，DNS给你返回一个别名，把你的请求指向了CDN的DNS，CDN的DNS根据用户所在的位置，给你返回一个最佳的CDN的节点，用这种方式可以把全球的用户分配到最优的节点上去，这样Dos攻击也就起不了什么作用了。

这里边CDN现在作为一个防Dos攻击的平台，它自身抗Dos攻击的能力会怎么样呢？我今天可能重点跟大家分享的是这方面的内容。本来是希望把我们这几年的一些研究做一个综合的介绍，但是因为最近频繁的出差，飞机又是频繁的延误，所以挑其中的两篇文章。这是这几年关于CDN安全的一些学术文章，其中有四篇，最后一篇还没有发表，有四篇是我们团队做的。CDN现在虽然这么重要，但是对它的安全性的研究并不是特别多。2012年的时候我的一个博士生在清华实验室开题要做CDN安全的研究，当时很多教授认为CDN这个话题已经非常老了，没有什么值得研究的。但是直到我们2014年的时候，这篇文章是发表在Security&Privacy里面，也是安全圈里面录取率最低的。这是去年CCS，四大学术会议之一关于CDN研究的一些研究。一直到我上一个博士生毕业，新的学生来了之后，说还有很多的问题值得研究。但是直到这个时候，我们发现其实关于CDN的安全研究还不是特别多。

刚才其实已经简单介绍了一下CDN的工作原理，这是我让我的学生去做CDN安全研究的时候找到的为数不多的一篇比较实际的论文，这是2009年的时候，他们说CDN究竟是提供了一种保护还是一种威胁？我们知道CDN靠大量的网络资源和计算资源，靠它分布在世界各地的这些服务器化解Dos攻击。但是这些资源如果被攻击者所利用，也可能会成为一个很大的Dos攻击的来源。这篇文章里面提到了几种方法，首先是攻击者可以绕过CDN的路由策略，把访问原始网站的请求直接发给了某一个节点。然后这些节点如果是这个攻击者同时发出一个请求，那么这个请求有可能同时到达这个目的地，成千上万个节点同时到达这个目的地，有可能对这个网站造成一定的冲击。当然怎么样去绕过这个缓存？因为如果内容一旦缓存了之后，它下次就不再向原始网站发送这个请求了。这个论文里面提出了一个方法，后面加一个Random，CDN就不知道这是不是一个新的内容了，因为每次都是一个新的，每次都会把这个请求发到服务器上去。

但是这种攻击是不是真正起到了放大作用了呢？其实这个攻击者要想把这些请求都打到服务器这边，他也耗费很大的带宽，其实放大比是1：1。怎么样才能做到真正的放大？有另外一种方法，就是他发起一个请求，这个链接马上就中断了，这个请求会在下一条转发到这个原始网站，原始网站把内容返回的时候，CDN这一端的链接已经终止了。也就是说他发了一个请求，断掉了，然后这个请求到达服务器，这个服务器有可能执行了大量的操作，把结果返回，但是CDN节点，这一端的链接已经没有了。

我们下面的研究，我的学生做完了这个调研之后，发现了另外一个很有意思的研究，我们把它叫做循环转发攻击，这个我们工作就是用实验证实了，针对于现在的CDN，我们可以构造一种转发的循环，可以绕过现在CDN厂商几乎所有的防范措施。而且我们测试了世界主流的16家CDN厂商，都可能受到不同程度的威胁。这种攻击我们并没有说真正的要构造一个这样的实验，但是说有可能会造成整个互联网基础设施的瘫痪。因为刚才说了，91%流量都跑在CDN上。
我们看一下CDN的转发过程，用户的网站一旦使用了CDN的服务之后，实际上在CDN的机制上要有一个转发的规则，把用户的请求转发到网站，是由原始网站的管理员来制定的，所以这里面攻击者是CDN的客户。客户会来决定最终的请求会转发到哪个服务器上去，于是个攻击者，其实也就是这个CDN厂商的客户，他告诉这个节点，说我的原始网站在CDN B，对CDN B说我的原始网站在CDN C，这样就构成一个循环，这个循环可以进行CDN厂商之间无休止的循环，大量的消耗CDN的资源。我们测试过的16个CDN厂商，包括Akamai、Clouoflare，包括国内的这些，都可以做到不同程度的影响。

可能有人会怀疑，你要发起一个攻击必须要成为这个CDN厂商的客户，你的身份就泄漏了。但实际上我们发现，绝大多数的CDN厂商都提供一个免费的测试帐号，你所需要的只是一个电子邮件地址，电子邮件地址可以随便注册。还有一个你的带宽，有一些是需要信用卡的，但是即便是信用卡，其实在国际上这种地下产业里面也不难弄到。我们发现其实可以构造几种类型的转发循环，最简单的循环就是把原始网站的地址指向127.0.1，这个循环就在一个服务器上自己转起来了。我们对于开源软件做过一些测试，发现如果你指定127.0.1，它很快就会把TCP的端口号资源占完了。我们远程对微软的Azure中国的CDN做了一个测试，在16个厂商里边，只有这一个是会受到影响。当然这个防范也很简单，把127.0.1不指定成地址。但是一般的CDN会允许你指向一个域名，这个域名又是由这个原始网站完成的，这个时候就不能用简单的静态的方法，要对解析之后的解决做一个过滤。这种方法不能预防另外一个，就是我并不是把它指向自己，而是指向CDN的另外一些节点。这个其实在第一篇文章里面我们也提到了，测量CDN的节点这个我们也做了一两年工程方面的工作，就是世界各地各个厂商的节点部署我们差不多都可以设到。

这里面因为这个权威服务器是攻击者来控制的，CDN在转发的过程当中，我可以决定你现在把这个请求转发给谁，这个地址是由DNS来决定的，而且DNS在这个里面给你缓存的时间相当短，比如只有一秒钟，这一次的请求，下次要重新再向我请求地址。这样的话，就可以在一个CDN内部构造一个循环，这个在我们16个所测试过的CDN厂商里面有7个是可以的，这个循环是可以转起来的。另外的为什么没有转起来？其实在大部分的CDN厂商，内部都有一个循环、转发、检测的机制，主要的就是在HTTP协议里面增加一个检测循环的头。下一个节点如果碰到这个头之后，他就认为这已经形成了一个循环，就把这个请求返回一个错误。

实际上在HTTP协议的标准里面已经定义所有的转发，都要在转发过程当中增加一个Via这个Header，但是并不是所有的厂商都遵循这个标准，有一些我们刚才说的那7个，实际上没有加任何检测循环的头，所以他就可以构造这样的循环。另外11个里面，有的是使用标准的Via，但是更多的是使用自己定义，百度是使用这个。一旦有了这样的检测，是不是我们的循环就转不起来了呢？我们发现有另外6个CDN厂商，他们虽然是有这个Header，但是有一个特殊的操作。比如前面这4个，他会把别人设置的Via Header重置，形成自己的。也就是再转回来的时候，刚才那个厂商自己设置的那个Via没有了，只有经过他自己的地址。还有这两个CDN厂商，他允许用户网站自定义一些规则，把任意的头过滤掉。也就是说别的厂商加了那个检测循环的头，可以被他过滤掉。这样的话，就构成这样一个环境，比如亚马逊的CDN增加了一个CloudFront，到了Akamai增加了一个Akamai。到了MaxCDN，他增加了一个规则，把这个头全部去掉了，这个循环又可以转起来了。

这样是不是这个循环就可以无限制的转下去了呢？还有一个限制，我们知道链接的超时，一直转下去之后，发起请求的那一方一直收不到响应，这个超时的时间，按照TCP大概是两分钟左右，但是很多的CDN厂商，这里面有不同的时间，比如有些是240秒。但是我们又回到了第一篇文章里面所提到的Abort-Forwarding技术，上面那个链接超时了，下面的链接并没有终止，会继续转发下去。其中有一跳超时了，下面这一跳并没有超时，会继续转发，于是又可以继续循环下去。还有一个就是刚才说的尺寸大小也有一定的限制，你既然可以过滤掉那个头，就可以把增加的头去掉，不因为每次循环增加了一个头而增加了大小，因为你又把那个头去掉了。这样的话，这个实验我们在多个CDN厂商之间冲击，我们的实验又不能对这个CDN厂商构成真正的危害，所以我们串进去自己的节点，联合我们实验室，我们再增加200毫秒左右的延迟，让这个循环转得慢一点，不会产生真正的危害。这样的话，我们可以做一个计数，知道它转了多长时间，转了多少圈。这样我们在真实的环境里面，用这种方法探测，五个多小时这一个循环可以转下去。后来终止，可能是因为网络，因为跨国家，跨我们实验室，条件也并不是很好，最后断掉了。但是理论上的超时时间不超过两分钟，现在实际上是在五个多小时。

现在究竟这个放大能产生多大流量呢？即便是循环，就像我们研究的400接力，可以一直跑下去，但是那个接力棒只有一个，那个流量也不会特别大。但是我们发现，其实有一个技术，就是CDN可以实现Streaming，你在看一个电影的时候，你不会把这个文件下载到CDN节点，CDN节点再传到你这儿来你再看，而是下载一小块的同时，已经在下一条传了。就相当于我们打球的时候，有多个球在天空飞，于是增加了这个Streaming以后，这个放大效果就非常明显。最近CDN厂商有一些只支持你发一个请求，你上传一个文件的时候，这个时候要支持Post的请求，要把文件上传到原始网站上去，CDN节点会一小块一小块的形成那么一个流，所有的CDN厂商都支持用这种方式，就可以把这个流量放到很大。
我们还有另外一个词是大坝攻击，我们把这个响应也增加进来了。比如说循环转了很多圈以后，这个时候我突然把这个原始网站的IP地址指向了真正的原始网站，原始网站会返回一个响应，这个响应又反向的转起来，整个流量比原先大得多了。最后一步，如果返回的这个文件，这个响应是一个压缩的文件，那又会是怎么样？我在请求的时候可以发一个Header里面，告诉你我支持的编码格式Gzip。CDN厂商发现你的请求不支持，但是响应里边确是个一个Gzip文件会解压，会消耗CDN的计算资源，又大大的放大了攻击的流量。这是CDN转发的攻击，这是今年在四大安全紧急学术会议的最佳论文，是第一篇最佳论文。

下面是我们正在进行的研究，还没有正式发表，我今天只是给大家做一个Demo。这里面说我们如何“黑掉”NSA，美国的国家安全局，这个“黑掉”我加了一个引号，其实跟NSA没有任何的关系。这个里面的演示效果是这样的，你要访问NSA的时候是这样的。这是我们从新加坡国立大学找到他们一个受影响的缓存服务器，如果是那边的用户访问NSA的话，他看到的效果是这样子的。但是为了不带来一些政治性的麻烦，我们压迫的演示是用Bing来做的，这个效果是一样的。大家看到，我们实际上是要访问一个Bing上不存在的网页，因为现在路径上从新加坡国立到Bing上有缓存，有CDN，可能还有防火墙。现在首先我们在这里面看到的这个页面是不存在的，Bing给你返回的一个301的代码让你重新定向到主页里面去。下面一个请求，现在再去访问的时候，中间的缓存已经被污染了，看到现在的地址是新加坡国立大学，这是我们在那里设置的一个代理，并不是说我们在新加坡国立大学黑了别人的一台机器，而是世界有一个实验厂，我们用帐号就可以使用他们的机器作为代理，但是那个代理我们没有做任何的操作，在那个节点上没有做任何的操作，而是他们学校使用的这个透明代理出了问题。这个页面我们并没有黑掉那个Bing，而是把中间的缓存污染了。

这个影响到的不仅仅是透明代理，也包括代理、反向代理、CDN和防火墙，包括一些开源软件，Apache、Squid等等。这是我们在世界范围内做的一个大规模的测量，我们这个发现已经报给Squid，这是使用最多的一个开源软件，就是透明代理用的比较多的，同时相关的一些厂商我们都已经报告了，我们希望在论文正式发表之前这些都已经写不玩了。Squid发了两个安全公告，这些问题都存在了很多年，而且都没有发现。报告人是我的学习陈建军，也是最佳论文的第一作者。

因为时间关系，大家如果有什么可以跟我联系。最后也是做一个广告，这是我和学术圈里面的一些朋友们组织的一个学术论坛，这里边来自世界各地的一些非常优秀的华人安全圈里面的学者会在我们的论坛上贡献和分享他们一些最新的研究成果。通过两种形式，一个是视频报告，大家可以订阅我们的微信公众号，我们的一些学术报告会通过网络直播的方式，我们到目前所有的学术报告全都是在网上直播的，大家只需要有一个手机，能够连上网就可以看到我们的学术报告。另外就是我们的自媒体的电子杂志，订阅到我们的公众号之后，每个星期有一份最新的研究成果的介绍。

以上就是我跟大家分享的内容，谢谢！