我们是一支开放源码的CDN团队，致力于CDN技术的发展与研究。
第一，要攻击CDN，必须了解CDN如何运作。下面简要介绍CDN的工作方式。
CDN的全称为“内容传送网络”(ContentDeliveryNetwork)，通过在整个网络中加速节点服务器，对网站的恶意流量进行防御，并将正常流量转发。简而言之，CDN通常有三种功能。
1.加速跨运营商：我们自己的网站通常只属于一家运营商(例如电信公司)，加速节点在每个运营商都有，而不同运营商的用户(例如联通)却没有这样做。
二、高速缓存：许多静态资源和某些页面更新(如首页)都很慢。这时CDN将根据浏览器的最大年龄和最后修改值以及管理员的默认值进行缓存，因此许多通信流CDN节点将不会每次都请求一个站点，CDN节点可以不会主动地将缓存的内容直接返回Sea。
三、恶意流量过滤：这是CDN非常重要的功能，也是CDN在许多网站上使用的原因，因为CDN能够抵抗大量流量攻击和常见的攻击(例如注入等)。只有正常的流量会被转发到网站。
以下是一些名词的解释：
源站：我们的网站叫源站。
逆向代理：CDN节点以逆向代理的形式向源站请求数据，即上述转发。
回源法：CDN节点请求数据到源站点的行为称为回源法。
咱们开始探索之旅吧。
进行OpenCDN测试时，我们遇到了一些小问题。一个没人访问的站点流量居然大得惊人，访问量也大。
OpenCDN在2分钟内有一个反向代理检测，但是这些时间加起来只有720次。四百万是从哪儿来的呢？接着，我们查看了日志，发现单个域名的日志数量达到了58G，但打开之后发现X-Forwarded-For字段(X-Forwarded-For机制，通过一层代理之后，将IP记录到一个IP中，以便源站使用CDN，从而获得真正的客户IP而非CDN节点IP)中充满了大量的IP，所有这些都是服务器的IP。在管理层确认之前，我们马上就明白了一些事情。果不其然，无意中将源站点的IP设置为CDN节点IP，当时并没有发现。这样就可以解释如此大的流量。因为每隔2分钟检测一次触发CDN节点的返回，并且该站点的源站是CDN节点本身，所以CDN就会不断地反转它自己的代理无限循环，从而将请求无限放大。在请求超时或标头过大(即X-For-For字段导致标头溢出)时，将放弃该请求。
设置网站源站IP作为CDN节点本身，可使CDN节点执行自反向代理的无限循环，从而放大通信量。
看起来很有意思，朋友们马上开始做实验。
为了加快CDN节点IP的速度，我们成功地设置了源站IP，然后在美帝的小vps上打开了webbench，用2000个线程来运行该站点(不管哪个CDN节点收到请求，请求最终都会聚集到源站设置的无辜CDN节点上)。但试验结果不理想，节点未发生宕机。利用IP反向查找找到一个网站，与我们共享一个CDN节点，并通过该CDN节点反向代理。由于不能为该节点收集性能数据，因此不能评估攻击。而我们的实验缺少了一次机会不停的循环会扩大CDN节点的流量，导致阻塞，还是这个2000线程可以自己打卡CDN节点？
因此，我们总结了一下，猜测这种节点对代理本身进行反向攻击的技术可能适用于以下情况：
您希望攻击一个CDN节点，但404页面并不会消耗太多的CDN站点，因为CDN中的一个站点会穿过它，CDN节点可能不会被破坏，而后面的站点已经被穿透死亡。此时如果节点执行自己的反向代理无限循环，他将吞噬所有流量，而无法吐出。这时将产生一定的流量杠杆，导致CDN节点发生异常。
但话说回来，这种攻击的防御方法非常简单，只要在设置源站IP时没有为CDN节点设置IP，就只在站点前端进行交互输入时才需要进行验证。
由于我们不能很好地评估不属于CDN节点的带宽和性能极限，因此黑盒操作可能不会带来什么，因此我们以自己的CDN节点为例。
在此期间我们继续探讨这个想法。既然一个节点可以无限循环，那两个节点又如何呢？成果是正面的，质量上有了改变。假定有这样一种情况。
还没有评论，来说两句吧...