浅析CDN技术与安全

本文笔者站从安全的角度出发，对CDN技术进剖析，揭开厂商使用CDN技术的风险、分析了黑客及黑产新的攻击方向。
实际上只要对CDN的工作流程有一定了解，并能够对数据报文的流向比较清楚，就能够获取其风险点了，在文中笔者只对动态页面的请求流程做讨论(静态页面一 般不回源)，至于静态页大部分由节点的webcache直接返回，一般不含敏感信息(cookie实际上是敏感信息)，所以不做讨论。

一．CDN工作流程如下图：

1.管理员或者站长将域名的DNS指向CDN厂商的DNS上(当然，根据选择不同也有可能使用CName方式，但都不影响数据流的流向)。
2.用户需要登录站点，请求DNS以便获得服务器IP(此处最终请求的DNS服务器为CDN厂商的DNS)
3.CDN厂商收到DNS查询请求及各种信息，通过各种算法选择一个离用户最近的节点，将该节点的IP 1.1.1.1作为服务器IP返回给用户(此处CDN厂商告诉用户一个假的服务器IP)
4.用户收到DNS响应，将HTTP请求(该处为登录请求，请求报文包含用户密码)发给1.1.1.1
5.CDN节点接收到请求包判断请求报文是否是动态页面，如果是静态则查看webcache，存在缓存直接返回缓存页面。如果是动态页面请求或者没有缓存的静态页面，节点则直接请求真实源，以便获取最新的内容。(注:此处对于动态页面的请求一般每次都会做回源操作)
6.接着就是服务器响应请求，此处不做讨论
二.CDN的软肋

由上图可知，对于网站的请求报文都会经过CDN厂商的节点(不做特殊操作的情况下)。因此安全隐患全都集中在了CDN厂商的节点上。一般一个节点会提供N 多个网站的加速。不管是360、腾讯、百度还是新浪，只要使用了商业化的CDN，就相当于孤注一掷，将自己的部分安全交给CDN厂商。

一旦攻击者控制了CDN厂商节点就可以轻易的进行抓包并分析。对于CDN厂商来说，毕竟不是专业的安全公司，所以在防护方面肯定会有所不足CDN厂商节点遍布全国，数量众
多，很难保证每个节点的安全性(再不行可试下ARP欺骗，从同段IP搞起)
三.从CDN看黑产动向
1.以往攻击者对目标发起攻击都会先对目标IP进行扫描和检测，但由于CDN的存在，很多攻击者无法直接获取到源IP，因此转而对CDN节点发起攻击，一 旦攻陷节点，那拿到站点权限就是迟早的事情，另外在这个信息发达的时代一般都是买一送多，大数据时代，一个结点的网站够撑死你了。目测接下来对CDN节点的攻击会成为黑色产业链的热门话题(估计已经很热了，只是我不知道)
2.CDN厂商实际上可以成为黑产的大数据提供商，对于应用软件你可以本地分析看是否在后台偷偷上传数据，对于CDN你能么，笔者建议少用免费的CDN服务，除非你已经麻木了，或者你做了特殊的手段。
3.大型企业会增加对自建CDN的安全维护成本，同时攻击者会将大部分时间放在对企业CDN网络的攻击上
四.由CDN到DNS劫持(只写思路，后面补上技术文档)
百度经常被黑、某黑阔站点又被hellen干掉了、XXX也被整了。到头来都是DNS劫持。难道DNS劫持就只能换个页面？或只能让用户访问恶意站点？看 了CDN的工作原理，结合APT攻击。长时间盯着就OK了。某天的某一时刻，某人说能控制某域名的DNS解析，问怎么利用。估计看了前面原理的人都想到了 如何进一步利用DNS劫持了，笔者在这里发表几个个人的方法，仅供参考。
1.搭建小型CDN网络，一个节点、一个自己的域名、一个自己搭建的DNS服务器。修改域名DNS指向自己搭建的DNS，从而将站点的访问流量全部牵引到自己的节点上，在自己节点装抓包软件(如何搭建CDN网络可以找找相关资料)
2.搭建中转服务器（代理服务器），将域名解析到自己的服务器上，由攻击者的服务器进行中转(实际上利用本地的HOST及某些数据转发软件就可以实现)。这个比上面一点好多了，少了个DNS服务器。
3.完全利用HTTP协议，写个PHP脚本，对接收到的报文进行转发，当然笔者在这边通过测试，该方法效率不高，刚开始忘记cookie的处理，导致用户无法登录，后面对cookie进行了处理后成功转发，但缺点是“速度像蜗牛”！
五.留给后面的大牛补充………
顺便宣传下winger的名言。

开发：no code you say G JB 逆向：no 0day you say G JB 脚本小子：no kits you say G JB 黑产：no data you say G JB 娱乐圈：no picture you say G JB