CDN流量放大攻击思路- 囧思九千.PDF

原原文文地地址址:/papers/679 0x00 背背景景 大家好，我们是OpenCDN 团队，专注于CDN技术的开发和研究。 首先，为了 CDN进行攻击，我们必须清楚CDN 的工作原理，这里我们再来简单介绍一下CDN 的工作模型。 CDN 的全称是Content Delivery Network （内容分发网络），通过在网络各处的加速节点服务器来为网站抵挡恶意流量，把正常流量进行转发。用简单点的话来说，CDN一般有三个作用 1. 跨运营商加速：我们自己的网站常常只属于一个运营商(比如：电信)，而加速节点遍布每家运营商，于是和网站不同运营商 （比如：联通）的用户访问起来就不会那么慢了。 2. 缓存加速：很多的静态资源以及一部分页面更新都是比较慢的 （比如首页），这个时候CDN就会根据浏览器的max-age和last-modified值以及管理员的预设值来进行缓存，于是很多流量CDN节点就不会每次都来向网站请求，CDN节点可以直接自作主张 3. 恶意流量过滤：这是CDN非常重要的一个作用，也是很多网站会用CDN的原因，因为CDN能为我们抵挡攻击大流量攻击、普通的攻击 （比如注入等），只有正常流量才会转发给网站。 这里还要说明几个名词： 源站：我们自己的那个网站就被称为是源站。 反向代理：CDN节点向源站请求数据的方式就叫反向代理，也就是上文所说的转发。 回源：CDN节点向源站请求数据的行为就叫做回源。 0x01 探探究究之之旅旅 我们在做OpenCDN测试的时候，遇到了一些小问题。发现一个没有人访问的网站居然会有流量，并且有着惊人的访问次数。 我们的OpenCDN有2分钟一次的反向代理检测，但是这次数加起来也就区区的720次，而这400万的访问次数是哪里冒出来的？然后我们查看了日志，发现单个域名的日志到达了58G之多，而 将其打开之后发现X-Forwarded-For字段中 （X-Forwarded-For机制是通过一层代理后记录一个IP，让源站在使用CDN后能够获得真实的访客IP而不是CDN节点IP ）充斥着大量有的IP，而且都是 本服务器IP。我们瞬间明白了什么，然后去管理端上验证了一下，果不其然地，我们一不小心把源站IP设成了CDN节点的IP，不过当时我们并没有发现。于是这么大的流量也好解释了，由于 2分钟一次的检测触发CDN节点的回源，而这个站点的源站是CDN节点本身，于是CDN就开始不断自身反向代理死循环，这样一个请求就被无限地放大了。当超时或者 EADER太大 （就是X- Forwarded-For字段导致 EADER溢出）的时候，请求会被丢弃。 把站点的源站IP设为CDN节点本身，能够让CDN节点进行自我的反向代理死循环，然后放大流量。 貌似有点意思，小伙伴们于是马上就行动起来了，进行了实验。 我们在安全宝上成功地将源站IP设置成了某个为我们加速的CDN节点IP，然后在美帝的一台小vps上开webbench用2000个线程去打这个这个站点 （无论是哪个CDN节点收到请求，请求最终都 会汇聚到那个无辜的被设源站的CDN节点），不过实验结果并不理想，节点没有宕机，通过IP反查找到一台和我们公用一个CDN节点的网站，通过这个CDN节点反向代理访问那个网站，出 现了卡顿和打不开情况，仅此而已。由于没法采集到安全宝的这个节点的性能数据，我们也没法 我们的攻击做出评估。而且我们这个实验缺少了一个 照组，到底是因为死循环把流量放大 导致CDN节点卡顿，还是这个2000线程本身就能把CDN节点打卡。 于是我们总结了一下，猜想这种节点反向代理自身的攻击手法可能可以适用于这样的场景 你想要攻击某个CDN节点，但是如果打404页面消耗不了太多，而如果打CDN中的某个站点，因为流量会穿透过去，可能还没有把CDN节点打掉，背后的站点早被穿透死了。这个时候，如果让节点进行自身反向代理死循环，他就会把所有的流量给吃进去，并且 不过话说回来，这种攻击的防御方式也异常简单，只要在设置源站IP的时候，不让设置CDN节点IP就行了，只要在网站前端交互输入的时候加点验证就行了。 我们考虑到我们没法 不是我们的CDN节点的带宽上限，性能上限有个很好的评估，黑盒式的摸索可能带来不了什么，于是我们拿我们自己的CDN节点开刀。 同时我们继续 这个思路进行探索。我们发现，既然一个节点能死循环，那两个节点怎么样？结果是肯定的，并且产生了质的变化。我们假设了这样的一个场景 我们的opencdn.cc在甲CDN服务商注册服务，并且在乙CDN服务商注册服务，然后我们得到甲CDN服务商的一个CDN加速节点，然后又得到乙CDN服务商的一个CDN加速节点。 然后聪明的你一定已经猜到了。我们把在甲CDN服务商