• 欢迎访问南思工作室官方站点.
  • 文章内容如有失效请文章下留言,我们看到后会第一时间处理。
  • 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏南思工作室吧。
  • 图片服务器和主服务器都挂了CDN,如有异常,请留言,我们会尽快处理。

关于CND的一些小总结

学习 nansi 4周前 (09-23) 209次浏览 0个评论
文章目录[隐藏]

CDN 安全小结

CDN 作为反向代理服务器,除非操作系统或者反向代理软件爆出严重的漏洞,其本身是不存在较大的安全问题的。扫描 CDN 服务器的端口往往会发现只开了 80(http)和 443(https),而这两个端口又不运行动态脚本,作为攻击者很难从这里下手。

尽管 CDN 服务器看起来固若金汤,但是攻击 CDN 可以从 CDN 运行逻辑入手。CDN 安全主要出现在环路攻击上,一旦流量形成环,则整个 CDN 会带着流量不断消耗自身的资源,造成拒绝服务。

CDN 环路攻击

设置 CDN 的时候有几个概念。

  • 加速域名
  • 源站地址
  • CDN 分配的动态解析域名

加速域名是用户控制的域名,用户将加速域名提交到 CDN 系统,系统会自动分配一个动态解析域名。这个动态解析的域名会根据来源 IP 的地区以及 CDN 节点负载情况动态解析成 CDN 某个节点的 IP。用户需要将加速域名的 CNAME 记录指向云服务分配的动态解析域名,这样当用户请求加速域名的时候,其对应的 ip 地址由动态解析域名进行解析。这样用户浏览器端的请求就会发送到 CDN 的一个节点上,然后由该节点向源站地址代理发出请求,得到响应之后返回给用户。

分析上面的过程,可以总结出 CDN 环路攻击有 5 种形式。

CDN 自身成环

将 CDN 的加速域名与源站域名设置成同一个,源站域名 A 记录指向 CDN 的一个节点。这样,当请求加速域名的时候,CDN 节点解析到源站的 IP 为其自身的 IP,循环自己请求自己,导致环路。

CDN 之间成环

将 CDN 的加速域名与源站域名设置成同一个,自己搭建 DNS 服务器,域名的 NS 记录指向自己的 DNS 服务器,即攻击者可以动态解析源站域名为需要的 IP。根据 CDN 分配的动态解析域名可以得到多个绑定了该加速域名的 CDN 节点的 IP,对每次加速域名的解析随机返回收集的 CDN 节点 IP 中的一个。这样,用户的 HTTP 请求的数据包就在 CDN 之间互相传递,如果控制好 DNS 解析的规律,则能形成一个环路,使数据包一直传递下去。

另外一种攻击方法是新建两个 CDN 加速域名,将源站指向对方,并通过动态解析域名的解析记录寻找两个加速域名的公共 CDN 节点的 IP。搭建 DNS 服务器动态解析这两个域名,使其 A 记录随机返回公共 IP 里的一个。这样只要访问其中一个域名即可让流量在这些公共 IP 之间流动起来。

不同 CDN 商之间成环

如果 CDN 服务商对自身 http 包传递次数做了一些限制,而有的 CDN 商可以去除掉这些限制的话,可以考虑在不同 CDN 商之间将流量成环。

CDN 和源站成环

如果能控制源站或者源站有 SSRF 的漏洞,正常配置 CDN 服务,把源站也变成一个反向代理服务器,地址指向 CDN 的一个节点。这样用户发起请求,CDN 请求源站,源站又回过头来请求 CDN。这样能较快的耗尽源站的资源,并且可能拖住一个 CDN 的节点。

DNS loop

将 a 的 CNAME 记录设置成 b,b 的 CNAME 记录设置成 c,c 的 CNAME 记录设置成 a。向 CDN 的一个节点发送请求 a 的数据包,则 CDN 会不断循环查询 DNS,对 DNS 服务器造成较大的流量。

CDN 测试遇到的坑

在最开始测试 CDN 环路攻击的时候,新建了多个加速域名,把加速域名的源站设置成下一个加速域名,依次连接起来,然后把最后一个加速域名的源站设置成自己控制的服务器。在服务器上监听端口,请求第一个加速域名,却没有收到任何请求。这个问题纠结了很长时间,直到意识到在 b 加速域名的 CDN 节点上可能没有 a 加速域名的信息。这样从 a 到 b 的请求会被丢弃掉,导致无法将流量传递。

如果 CDN 允许配置回源 host 的话,那么 CDN 环路攻击依然可以生效。

CDN 环路攻击的解决方案

从攻击的方法上可以看到,阻止 CDN 的 HTTP loop 最简单的方法是禁止 CDN 的加速域名与源站域名设置成同一个。除此之外,实际上还需要做一些其他的防护手段来避免 CDN 之间成环。

阿里云会在 HTTP 请求头中加一个 Via 项,里面记录了这个请求经过的节点信息。如果节点检测到 Via 中和本节点的特征匹配的话,则直接返回HTTP/1.1 508 Loop Detected。经过测试发现阿里云会把多个的 Via 项拼起来,尝试干扰服务器对 Via 的判断没有成功。

通过 Via 来判断是一个比较好的解决思路,也是 RFC 中推荐的方法。有的 CDN 会在 HTTP 请求头里加一项特殊的X-Daa-Tunnel: hop_count=1头来计数,用户可以自己指定一个非常小的负数,CDN 节点需要一点一点加很久才能达到阈值,导致仍然可以受到攻击。

解决好环路的判断问题是避免 CDN 流量转发放大造成 DoS 的根本。


南思工作室 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:关于 CND 的一些小总结
免责声明:本站一切资源仅用作交流学习,请勿用作商业或违法行为!如造成任何后果,本站概不负责!
喜欢 (7)
关于作者:
南思工作室管理员
发表我的评论
取消评论
表情 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址