浅谈cdn-存储的环路攻击
1. 什么是环路攻击?
顾名思义，环路攻击就是基于存在环的网络链路对服务端产生攻击。
举一个简单的例子，将cdn域名（a.com）的源站设置为存储域名（b.com），然后将存储域名（b.com）的源站设置为（a.com）；
在cdn没有配置任何缓存的情况下，这时候去访问一个存储源站不存在的文件路径，想一想接下来会发生什么？
环路攻击1
如图，cdn和存储层形成了一个环，通过服务端的资源借力打力，一个请求就可撬动的巨大杠杆，通过无限循环的网络链路来占用大量资源，来实现攻击的目的。
实际上由于cdn会有大量的边缘节点，环路攻击的放大效果会更大，往往会以很快的速度指数级增长，占用大量的服务端资源，影响现网业务。由于存储层的承载能力通常都远小于cdn，所以受到环路攻击时存储层的影响相对会更大，本文将从存储层的角度来谈一谈环路攻击。
环路攻击2
2. 环路测试
我们通过腾讯云的cdn和阿里云的oss进行了一次简单的环路测试。
- 配置cdn源站和存储源站，组成一个简单的二元环。
- 配置cdn不缓存状态码，不透传自定义头部。
- 发起一个简单的下载请求（源站不存在该对象）。
10分钟后在cdn的监控上统计到了峰值200k的请求数，同样在存储的监控中可以看到出现了相同数量级的请求。
cdn请求数
可以看到这种环路实测会很大程度地放大请求的数量，每一个请求都会占用服务端10s的时间（cdn超时时间），从而达到攻击的目的。
3. 如何防御？
从服务端的角度去看，这种成环的链路显然是不能接受的，相当于是把自己当肉机器来攻击自己。所以一定要避免这种无限循环的链路发生，那么应该如何设计才能避免这类问题呢？
- 增加标识头部
最简单的例子就基于x-forwarded-for头部来中断环路
X-Forwarded-For:client, ip1, ip2, ip3
x-forwarded-for 会标识请求经过的代理路径，服务端只需要限制XFF的路径长度，即可以有效地限制环路攻击地长度。
除了XFF也可以通过设计自定义的头部来记录访问路径，像 oss 会通过oss-bucket头部来记录曾经访问过的源站bucket列表，当该某个bucket重复出现时，就标识着出现环路，就结束这个请求，不再回源，这样同样可以避免在回源中环路的发生。
- 频控/流控
增加标识头部可以有效避免自身成环，或者一些勿配导致的环路；但是显然如果是以攻击为目的的环路还是难以防范的，攻击者完全可以在环路的某一个节点删除这些标识头部，会让服务端错误地认为这是一个没有带环路的请求，从而继续回源。
所以要从根本上解决无限环路的问题还是要在服务端限制请求的频率和流量。
存储层只要针对每一个客户做好回源的流控和频控，甚至更细粒度的路径级控制，就能有效地限制这个环路的无限增长。
流控频控
比如限制回源流量为1000qps，就算经过cdn多级边缘节点放大最终，下一轮环路再次回到cdn的有效请求也只有1000qps，可以有效规避这个问题。 - 缓存超时
限制流量和qps的方法在大多数场景都是可以有效规避环路的问题。但是并不能结束这个环路，只要这个链路还在，这个请求就会一直占用服务端qps/流量上限的资源，永远停不下来，很明显这还是对资源的一种浪费，并不是最优的防御方案。
那么如何才能完全中断掉这个环，让其在有限的请求里停下来？- 这里有一个想法：把超时返回的错误码一般是
500 Internal Error缓存住，如果有相同路径就直接用缓存的500 Internal Error错误码，而不用再回源，这样环路就可以很快中断，从而阻断攻击。 - 但是这个方案可能会对正常请求产生影响，如果是源站偶发的抖动导致的超时，这时候缓存超时的状态就会导致缓存生效时间内请求全部失败，干扰了正常业务的重试。
- 为了避免影响正常的业务重试，可以考虑针对单路径出现
500错误码的qps超过一定阈值时，再记录缓存，这时候就可以将这个路径的超时访问识别为攻击请求，不继续回源直接返回500错误码的缓存；这样在缓存生效的时间内，这个路径的超时环路就会断掉，从而降低该类请求对资源的永久占用；
缓存超时
- 这里有一个想法：把超时返回的错误码一般是
本文仅为一种环路攻击的防御思路，只是做过一些小规模的测试，也欢迎大牛们进行验证或者分享更好的方案。如有不足之处或者逻辑上的错误还请提出，谢谢您的阅读。
