利用CDN自身机制破坏CDN DoS防护

 

内容分发网络（CDN）通过其全球分布的网络基础结构提高了网站的访问性能和可用性，这有助于在互联网上以CDN为动力的网站的兴旺发展。由于以CDN为基础的网站通常会经营重要的业务或关键服务，因此攻击者有兴趣攻击这些高价值的网站，以最大的影响力造成严重破坏。CDN凭借其巨大的带宽资源吸收了分布式攻击流量，因此人们普遍认为CDN供应商为CDN驱动的网站提供了有效的DoS保护。

本文揭示了可以利用CDN转发机制中的实现或协议弱点来破坏此CDN保护。通过发送精心制作但合法的请求，攻击者可以对其背后的网站发起有效的DoS攻击，特别是在本研究中提出了三种CDN威胁。通过滥用CDN的HTTP/2请求转换行为和HTTP pre-POST行为，攻击者可以使CDN起源的带宽饱和，并耗尽起源的连接限制。更令人担忧的是，某些CDN供应商仅使用少量的具有较低IP转换速率的流量转发IP来建立与源的连接。仅通过切断特定CDN起源的连接，此特征就为攻击者提供了一个绝佳机会，可以有效降低网站的全球可用性。

 

0x01 Introduction

通过在不同地理位置（通常跨多个互联网主干网）部署大型代理服务器，内容分发网络（CDN）可以作为地理分布的网络，支持网站在计算资源和网络带宽方面都具有高容量。由于其减轻流量的好处和全球可访问性，CDN已成为互联网生态系统中不可或缺的一部分。 CDN供应商还一直在宣传其抵御DoS攻击的能力，为CDN通过互联网的成功扩展做出了贡献，在CDN后面部署了越来越多的网站。例如，超过50％的Alexa前1千网站和超过35％的Alexa前1万的网站都部署在CDN之后。

但是，在本文中，通过实证研究六个CDN的转发行为，发现CDN本身可被滥用来攻击CDN背后的来源（网站服务器）。通过向CDN发送精心制作但合法的请求，攻击者可以对源发起DoS攻击，从而破坏CDN DoS保护。简而言之，揭示了以下三个威胁：

•HTTP/2带宽放大攻击（HTTP/2 Bandwidth Amplifification Attack）：发现CDN在客户端CDN连接中仅支持HTTP/2，因此攻击者可以滥用CDN的HTTP/2-HTTP/1.1转换行为来发起针对源的带宽放大攻击（例如，达到放大Cloudflare的系数为132）。分析了HTTP/2引入的HPACK压缩机制，该机制加剧了威胁，并且还揭示了可以滥用HTTP/2的并发流和Huffman编码来进一步提高带宽放大因子。

•Pre-POST慢速HTTP攻击（Pre-POST Slow HTTP Attack）：在本研究中分析的六个CDN中，有三个在接收到POST标头后就开始转发HTTP POST请求，而无需等待整个POST消息主体。可以滥用此POST前行为来耗尽来源的连接限制，并使其他合法用户的请求一直等待，从而导致针对来源的HTTP DoS攻击缓慢。更糟糕的是，这些CDN的HTTP/1.1 POST转发和HTTP/2 POST转发行为都容易受到此威胁的影响。

•全球可用性下降攻击（Degradation-of-Global-Availability Attack）：通过将请求发送到每个CDN的全球代理IP（入口IP）以模拟全球客户端访问，对每个CDN的流量转发IP（出口IP）的分布进行了大规模测量。结果表明，CDN将分配少量出口IP来访问源，从而降低IP交换速率。因此，攻击者可以通过切断一个或一小组CDN起源的连接来利用此特征来有效地降低由CDN驱动的网站的可用性，从而阻止大多数全球客户端访问该网站的服务。例如，对于MaxCDN（现已被StackPath收购），如果仅断开一个CDN起源的连接，则超过90％的全球访问将被阻止从CDN背后的源获取资源。

总而言之，本文集中于如何打破CDN安全保护，许多网站都认为CDN安全保护是值得信赖的。通过对研究不足的CDN源连接进行经验安全性分析，探索了滥用CDN的转发行为对CDN驱动的网站发起DoS攻击的可行性。 HTTP/2放大攻击基于先前的研究，但是尚未探讨它是否适用于受CDN保护的网站，因此，进一步提出了通过CDN对HTTP/2放大攻击的真实评估，并深入分析了HPACK机制。

此外，发现CDN供应商容易受到攻击的HTTP POST转发策略，可以利用该策略发起Pre-POST慢速HTTP攻击。最后，基于对CDN IP分布的大规模测量，利用了CDN的低IP搅动率，可将其用于发动全球可用性下降攻击。结果表明，这些攻击对CDN驱动的网站构成了严重威胁。

众所周知，DoS攻击会对网站造成严重损害，从而导致金钱和这些网站客户之间的信任度损失。由于以CDN为基础的网站通常会运行重要的业务服务（例如银行，在线购物商店，新闻服务器），因此针对CDN隐藏的来源进行实际的DoS攻击可能会严重破坏这些网站的业务和声誉。

 

0x02 Background and Threat Model

A.背景

内容交付网络：CDN被广泛用于改善网站的性能和安全性。对于以CDN为动力的网站，CDN通过使用请求路由机制（例如，基于Anycast或DNS的方法）来加快连接性能，该机制将客户端的Web请求重定向到地理上分布的CDN代理（CDN入口IP ）。

收到Web请求后，CDN代理首先检查HTTP标头字段，尤其是Host和URI标头字段。如果所请求的Web资源已经缓存在CDN中，则代理将内容直接提供给客户端。否则，代理将通过出口IP将请求转发到源，如下图所示。结果，CDN将传统的端到端连接分为两个阶段，即客户端CDN连接和CDN源连接，作为客户端和源之间的中间人。

因此，从客户端角度来看，当客户端CDN连接的协议不同于CDN起源连接中使用的协议时，CDN首先必须充当协议转换器，例如，CDN转换客户端CDN HTTPS连接到CDN源HTTP连接。其次，CDN旨在加快最终用户的请求延迟，因此CDN必须尽可能快地优化请求的从原点转发。最后，为了提高CDN缓存命中率并减少回原点转发，CDN可以添加一个额外的缓存层来缓存网站的资源内容以供其全球代理使用。

请求路由机制：请求路由机制对于CDN提供最佳的CDN代理以处理请求至关重要。但是，如果代理IP是已知的，则可以绕过此机制；普通用户可以直接将请求发送到选定的代理IP，而无需请求路由阶段，否则，该阶段会将网站域名与CDN代理进行映射。

CDN中的HTTP/2协议： HTTP/1.1协议为万维网奠定了基础，但是每个请求和响应中重复的冗余HTTP标头浪费了网络带宽，并且降低了连接性能。因此，发布了HTTP/2以解决这些问题：标头压缩减少了HTTP/1.1中不必要的网络流量，并且多路复用流允许在单个TCP连接中进行多个请求。当前，几乎所有的CDN都声称它们支持HTTP/2协议。

CDN供应商的简要比较：全球CDN服务市场价值数十亿美元，并且以越来越快的速度增长，一些CDN供应商在这个蓬勃发展的市场中竞争。根据CDN市场份额报告，Akamai，CloudFront，Cloudflare和Fastly是该市场的主要参与者，因此，这些供应商自然应该在CDN的大多数研究范围内。但是，由于Akamai仅向企业客户提供CDN服务，因此研究未包括该服务。

在本研究中，选择了六个CDN供应商（Cloud Front，Cloudflare和Fastly，这是前面提到的三个主要参与者，以及CDNSun，KeyCDN和MaxCDN），它们为单个用户提供免费试用帐户注册。在这六个CDN供应商中，只有五个需要电子邮件注册，并且只有CloudFront需要额外的信用卡验证。

从攻击者的角度来看，不需要严格的身份验证的这类CDN供应商，使攻击者可以在不暴露其敏感个人信息的情况下揭示和利用特定的CDN转发行为。此外，这六个CDN供应商涉及两个主要的请求路由机制：Cloudflare和MaxCDN使用Anycast路由，而其他四个CDN使用DNS映射，这有助于扩大研究范围。

B.威胁模型

通常，网站使用CDN来提高其安全性和全球可用性。 CDN通常提供Web应用程序防火墙（WAF）服务，以规范对网站来源的请求。此外，CDN可以利用大量的地理分布代理来吸收分布式拒绝服务（DDoS）攻击。最后，通过托管在CDN上，网站可以将其“真实”源IP地址隐藏在潜在的攻击者面前。

在本研究中，假设攻击者作为普通客户端能够向CDN发送恶意但合法的请求。还假定受害网站托管在CDN上（或由恶意CDN客户无意间托管在CDN上）。在这里，通过研究，旨在发现一些可滥用的特定但基本的CDN特征。特别是，如果可以滥用CDN的转发机制，则攻击者可能能够操纵源自CDN的连接。结果，这些恶意连接可能耗尽源的有限网络资源，从而导致针对源的DoS攻击，如下图所示。

 

0X03 HTTP/2 Bandwidth Amplifification Attack

到目前为止，根据实验发现在其客户端CDN和CDN源连接中，CDN仅在客户端CDN连接中支持HTTP/2。因此，当接收到HTTP/2请求时，CDN必须将HTTP/2请求转换为HTTP/1.1请求，这可能会在协议转换过程中引入新的攻击媒介。在本节中，通过进一步研究跨越六个CDN的协议转换行为，揭示了可以利用所有六个CDN对它们所服务的网站源发起带宽放大攻击。

A.攻击面分析

Half-Done HTTP/2 Support：几乎所有CDN供应商都声称他们当前支持HTTP/2 。但是，由于CDN必须同时维护客户端CDN连接和CDN源连接，因此尚未对HTTP/2转发行为进行详细研究。在这里，首先通过将网站的源设置为仅HTTP/1.1服务器，仅HTTP/2服务器以及HTTP/1.1＆HTTP/2服务器，来探索CDN的HTTP/2支持行为。然后，使用curl工具作为客户端，以HTTP/2协议访问CDN服务。

实验表明如上表所示，CDN在客户端CDN连接中支持HTTP/2，但在CDN源连接中仅使用HTTP/1.1，即使源支持HTT /2。因此，这些CDN必须在HTTP/2和HTTP/1.1协议之间转换Web请求，这可能会带来新的安全威胁。甚至更糟的是，如下表所示，这些CDN（除Fastly外）默认为其客户网站打开HTTP/2客户端CDN连接支持，从而直接将其客户网站暴露于可能的协议转换威胁。此外，由于三个CDN（Cloudflare，CDNSun和KeyCDN）甚至没有提供关闭此类HTTP/2支持的选项，因此导致的严重性也会增加。

Primer on HTTP/2：HTTP / 2的主要目标是减少延迟并最大程度地减少协议开销。首先，HTTP / 2协议在单个HTTP/2连接中支持多个并发双向流，从而减少了不必要的TCP握手过程，并支持完整的请求和响应多路复用。例如，在客户机与CDN的连接中，客户机与CDN建立一个HTTP/2连接，使用两个流通过“ path1”和“ path2”请求资源，如下图所示。

在HTTP/1.1中，标头字段未压缩。由于网页已经增长到需要数十到数百个请求，因此这些请求中的冗余头字段不必要地占用带宽。因此，在HTTP/2中，引入HPACK标头压缩主要是为了减少由HTTP/1.1中重复的请求和响应标头引起的不必要的网络流量。

根据HPACK机制，在客户端CDN连接中，客户端和CDN（作为HTTP/2服务器）都维护以前看到的标头值的索引动态表，随后的重复标头字段被替换为引用值的索引。由于许多标头字段（例如：authority，Cookie和用户代理）是重复的，因此该机制具有很高的表命中率。因此，替代索引而不是完整的标头字段在网络中传输，从而减少了传输的字节数。

当客户端打开第二个流以发送另一个“ path2”请求时，重复的标头字段（例如cookie）将被替换为索引（因此，这些字段未在上图的“ stream2”中显示）。这些机制大大减少了报头开销并提高了传输性能。

Attack Principle：当CDN将这些请求转发到源时，必须将在HTTP/2中索引的所有标头字段扩展为HTT /1.1请求，从而导致带宽放大。如上图所示，这种机制导致两个具有相同大cookie的大HTTP/1.1请求，这导致CDN起源连接中的带宽放大，放大率几乎为2。

在一个HTTP/2连接中，放大率相对于并发流的数量是线性的。建立HTTP/2连接时，协商并发流的最大值。测量CDN的流限制，并将它们列出在下表中。在所有六个CDN中，允许的最大并发流都大于100（RFC中的建议值）。

因此，为了使攻击者能够在CDN起源的连接中获得最大的放大率，精心设计的攻击HTTP/2请求都可以使用具有相同大数值的标头字段，例如，给定给定值的cookie广泛用于HTTP请求中。除cookie字段外，攻击者还可以使用HTTP/2协议中定义的其他标头字段，例如user-agent和Referer，这些标头字段也转发到源。标头字段值的大小受索引的动态表的大小限制，该索引也在HTTP/2连接期间协商。如上表所示，跨CDN的最大表条目大小为3072B，表大小为4kB。因此，精心设计的攻击性HTTP/2请求可以使用两个标头字段来填充索引表，从而使转换后的HTTP/1.1 CDN起源请求具有最大大小。

B.真实攻击分析

实验设置：基于先前解释的分析，进一步评估了横跨六个CDN的这种放大攻击的严重性。在每个CDN后面部署Apache服务器之后，启动与六个CDN中的每个CDN的HTTP/2连接以发送攻击请求，这些请求的设计如下：

为了获得最大的放大率，使用两个带有大字符串的cookie字段来填充4kB HTTP/2动态表。假定最大表条目大小为3072B，则通过从总4kB动态表大小中减去额外的开销字节来计算两个cookie值的长度。额外的开销字节由表条目开销和其他标头字段值（例如：authority和user-agent）确定。这两个Cookie在所有并发流中保持相同，因此除了第一个流外，它们将以与索引相同的方式进行传输。请注意实际上使用两种类型的:path标头字段值来评估放大率。

在实验中，为了探索并发流对放大率的影响，更改了一个HTTP / 2连接内的并发流数，并使用tcpdump捕获了客户端CDN连接和CDN起源连接中的流量评估放大系数。

实验结果：根据上图，当并发流的数量增加时，带宽放大率也增加。如下图所示，当并发流的数量增加时，分组放大率也增加。当并发流达到一个HTTP/2连接允许的最大数目时，放大率达到最大值。当流数量超过一个HTTP/2连接的最大允许数量时，HTTP/2客户端必须等待之前的流关闭，并且数据包比率下降，如下图所示。达到允许的并发流的最大数量后，比率会波动。

带宽放大率总结在下表中，可以看到这种HTTP/2–HTTP/1.1转换威胁是现实的。它可能会破坏CDN保护并导致对源的严重DoS攻击。

放大因子分析：从图中可以看到带宽放大率主要取决于并发流的数量。通过对HTTP/2规范的进一步分析，还发现其他影响带宽放大率的因素，例如霍夫曼编码和:path头字段。

•Huffman编码：在HPACK压缩机制中，Huffman编码用于进一步压缩标头值。此霍夫曼代码是针对HTTP标头统计生成的，其中ASCII数字和小写字母的编码较短。一个字节的最短编码为5位长；因此一个字节可获得的最高压缩率是8bit:5bit霍夫曼编码（小37.5％）。因此除了并发流之外，还可以滥用霍夫曼编码以最大化放大率。因为首先使用Huffman编码压缩HTTP/2标头，然后在CDN源连接中将其解压缩，所以生成的HTTP/1.1标头的大小将近8/5 = 160％。

因此在实验中，两个cookie值由字符0、1、2，a，c，e，i，o，s或t组成，它们具有RFC中定义的最短霍夫曼编码（5位）。使用霍夫曼编码，可以达到上表中列出的放大率。

•:path标头字段：在实验中还发现:path标头字段有助于放大率。如果直接在所有攻击请求中使用:path:/，因为它是静态表中的预定义索引，则只需在所有HTTP/2并发流中传输1B即可。但是在万维网中，URL的长度可以不同，并且攻击者通常使用随机URL绕过CDN缓存或WAF规则。因此，在每个HTTP/2流中，还将不同的随机字符串附加到:path标头字段中，形式为:path:/?random_string。

如上表所示，在每个生成的HTTP/1.1连接中，:path:/标头字段也转换为1B。当在每个HTTP/2请求的:path头字段中使用随机值/?random_string时，该字段中的随机值是非重复值，因此不会出现在动态表中。根据HPACK机制，该值将以其原始格式或使用霍夫曼编码格式（两者中的较短者）进行编码。在上表中，可以看到:path:/?xxxyy在HTTP/2中消耗8B（对于:path字段的索引为1B，对于/?xxxyy为7B），并且在每个HTTP/1.1请求将是7B。

在实验中，发送这两种类型的:path标头来评估带宽放大率并获得不同的结果。这些差异的原因是，当并发HTTP/2流的数量增加时，:path标头字段的长度开始影响放大率。在实验中，使用:path:/形式时，攻击者CDN连接前端流量（FB）的网络流量约为数千，例如每秒5,000字节，而CDN起源的连接后端流量（BB）约为数百万，例如每秒600,000字节。放大率是BB / FB。

另一方面，当使用:path:/?xxxyy形式，并且发送n个（例如100、128或256）并发HTTP/2流时，与:path:/形式相比，攻击者与CDN的连接将为（FB + 7n）（n个HTTP/2流，每个流大于7B），以及CDN源连接为（BB + 6n），（n个HTTP/1.1连接，每个连接大于6 B）。因此对于:path:/?xxxyy形式，放大率将为（BB + 6n）/（FB + 7n）。

正如所说明的，FB约为数千，而BB约为数百万。因此有以下数学不等式：

为简单起见，假设F B = 5，000，BB = 600，000，当对n（并发流数）使用128或256时，不等式变为：

因此可以看到，为了获得最大的放大率，应该对HTTP / 2攻击请求进行特殊设计，使其尽可能使用HPACK索引机制。

总结：对于攻击进行了一个受控实验，通过与一个CDN节点仅建立一个HTTP/2连接来获得网络流量放大率。但是，从作为客户端的攻击者的角度来看，他可以使用不同的CDN节点发起数千个HTTP/2连接（例如，发现128,906个CloudFront IP可用于攻击）其他CDN的IP地址。根据获得的放大率，可以严重消耗CDN源连接的网络带宽，从而对源的性能产生不利影响。

鉴于默认情况下，这六个CDN中的五个中的HTTP / 2支持是打开的，甚至在三个CDN中甚至都不能关闭，因此可以看到这种威胁是严重的，并且会影响这些CDN上托管的所有网站。

 

0x04 Pre-POST Slow HTTP Attack

在本节中介绍Pre-POST慢速HTTP攻击，该攻击利用CDN基础结构对源进行DoS攻击。与依靠大型僵尸程序的传统DoS攻击相比，这种攻击更隐秘，更难以为源防御，因为精心设计的请求是合法的，并且是从CDN发起的。

A.攻击面分析

Pre-POST慢速HTTP攻击旨在耗尽来源的连接限制，并使其他合法用户请求匮乏。从根本上讲，该攻击的行为与传统的慢速POST攻击相同。通常，由于CDN分离了客户端CDN（包括攻击者CDN）和CDN起源的连接，因此CDN自然可以抵御传统的慢速POST攻击。但是，通过实验，发现六个CDN中的三个仅在接收到POST标头后就开始转发HTTP POST请求，而无需等待整个POST消息主体，这种Pre-POST行为使攻击者能够保持CDN源连接尽可能长时间保持打开状态，从而使攻击者可以耗尽源连接的限制。

慢速HTTP DoS攻击：根据卡巴斯基2018年第四季度情报报告，与HTTP相关的攻击的总持续时间一直在增长，占全年DDoS攻击时间的80％左右。该报告发现表明，攻击者正在转向复杂的混合HTTP攻击技术，例如缓慢的HTTP DoS攻击。

与暴力泛洪攻击相比，慢速HTTP DoS攻击更隐蔽，更高效。缓慢的HTTP DoS攻击利用了HTTP协议的优势，HTTP协议旨在将连接保持打开状态，直到数据接收完成为止。因此，可以滥用请求流程的不同阶段来发起缓慢的HTTP DoS攻击。慢速Header攻击发送部分报头，慢速Read攻击有意缓慢地接收响应数据，而慢速POST攻击以惊人的慢速发送已发布的数据。所有这些攻击旨在尽可能长时间地保持与目标服务器的大规模连接，导致目标的并发连接耗尽，并使其他正常用户请求一直等待。

攻击原理：通常，为了防止由于DoS攻击而导致的不可用性，CDN会断开攻击者CDN和CDN源连接的耦合，并吸收所有泛洪流量。但是，对于由CDN驱动的网站进行缓慢的HTTP DoS攻击的适用性仍然研究不足。

通过进一步的分析和实际实验，发现六个CDN中的每个仅转发请求，直到接收到完整的HTTP标头为止，因此能够防御缓慢的Header攻击。此外，在转发HTTP GET请求时，CDN源传输依赖于攻击者客户端CDN的传播。因此，CDN能够阻止慢速读取攻击。

发现CDN呈现两种不同的POST转发行为，当CDN接收到对原点的POST请求时，CDN将面临何时将POST请求转发到原点的选择。为简单起见，CDN仅在完成接收整个POST消息后才能转发POST请求。但是，POST请求可能包含大型消息正文，这将花费很长时间才能接收，因此会延迟请求转发。 CDN也可以仅在完成接收到POST请求标头后就开始转发POST请求，然后在同一HTTP连接中顺序转发随后接收到的POST消息。这种POST前转发行为无疑可以促进源较早接收POST请求。但是，它还使攻击者能够将CDN起源的连接保持尽可能长的打开时间。

B.真实攻击分析

实验设置：在的实验中建立了一个自建的Apache网络服务器，并将其部署为六个CDN背后的源网站。 Apache Web服务器的并发连接限制配置为默认值1000 。

从攻击者的角度来看，设计了POST请求以探索CDN的请求转发行为。特别是，要发布大型邮件，攻击者可以直接在Content-Length标头字段中指定大小，或使用Chunked-Encoding发送动态生成的数据，两者的目的都是缓慢地发送POST邮件。在这里，为简单起见，使用Content-Length字段指定HTTP消息正文的确切大小，并且POST消息正文的发送速度非常慢，需要300秒才能完成传输。

同时，在网站源位置，使用tcpdump工具捕获收到CDN转发的HTTP POST请求的时间戳（相对于请求发送时间），以及CDN源连接保持打开状态的时间。发送1000个并发POST请求并重复此过程30次后，得到下表中所示的平均结果。

可以看到CloudFront和Fastly一旦收到转发请求标头就开始转发POST请求，而CDNSun，KeyCDN和Cloudflare仅在收到整个消息后才开始转发POST请求。 MaxCDN也将在0.74 s之后开始转发POST请求，但是当保持打开时间超过15 s时中止连接。

显然，对于CloudFront，Fastly和MaxCDN，CDN源连接的保持打开时间取决于客户端CDN连接的保持打开时间，而CDN连接的保持打开时间直接在客户端的控制之下，因此具有很大的潜力。因此，攻击者可以利用这种Pre-POST转发行为来发起缓慢的HTTP DoS攻击：攻击者可以利用CDN并发建立并维护数百个甚至数千个这些POST连接，从而充分利用CDN（从而对源产生不利影响）。它将迅速耗尽来源的所有连接资源，并使其他正常请求匮乏，从而破坏了CDN提供的DoS保护。

实验结果：此外通过CloudFront，Fastly和MaxCDN对的自建源Web服务器（连接限制为1000）进行了这种Pre-POSTPOST攻击，持续了300 s。从另一个角度来看，作为普通客户端，每5s定期测量一次客户端-CDN-源请求延迟，以探查起源连接资源是否耗尽。

对于CloudFront和Fastly，为耗尽源1000个连接的限制，同时向CDN发送1100个慢速POST请求。在源位置连接资源已耗尽，其他请求却一直等待。因此，如下图所示，对于CloudFront，普通客户端的请求延迟上升到90 s（返回HTTP 504网关超时），对于Fastly（返回HTTP 503服务不可用）上升到15 s，这证明了DoS的成功攻击。

由于MaxCDN将在15秒后中止POST连接，因此在攻击期间，每秒定期启动100个新的并发连接。如下图所示，连接数在1500左右波动，因为MaxCDN依次中止了先前的15秒持续连接。同时，如上图所示，由于普通客户端请求与针对释放的连接资源的攻击请求竞争，普通客户端的请求延迟在15s以下波动。 MaxCDN的这种现象说明了服务质量（QoS）攻击，该攻击旨在降低性能而不是完全禁用服务。

Pre-POST HTTP/2攻击：鉴于CDN在客户端与CDN的连接中支持HTTP/2，还将进一步评估针对源的慢速HTTP/2 POST攻击。为了使用HTTP/2的复用流功能，与CDN建立10个同时HTTP/2连接，并在每个HTTP/2连接中发送100个POST请求。 POST请求的设计如下：

如下表所示，除Fastly之外，获得了与HTTP/1.1相同的POST转发行为。结果显示，对于10个CDN源连接，平均保持打开时间为299.41059 s，快速启动每个连接的第一个请求的预POST转发。同时，同一连接中的后续POST请求在Fastly中排队300 s，在此期间Fastly必须完成接收后续的整个POST消息，从而导致990个CDN起源的连接的平均保持打开时间为0.84946s。推测此现象的原因是，对于每个HTTP/2连接它都会快速维护一个POST请求队列，因此，仅在最重要的POST请求完成后才转发后续的POST请求。

对于目标源，此连接耗尽攻击的工作方式与直接慢速HTTP攻击相同，但是消耗了攻击者更少的资源，例如，攻击者只需维护与CDN的一个连接，然后将其滥用以代理并最大化同时进行CDN起源的连接。

总结：通过实际实验，显示出六个CDN供应商中的三个支持POST前转发。这种POST前转发行为引入了新的攻击媒介，以打破CDN保护，并启用针对以CDN为动力的网站的来源的资源耗尽攻击。

 

0x05 Degradation-of-Global-Availability Attack

因为可以绕过CDN的请求路由机制，并且可以直接访问CDN代理服务器，所以攻击者可以直接向全球分布的入口IP发送精心设计的攻击请求，进行DDoS攻击，如下图所示。

收集了大量CDN入口IP（代理IP）后，评估了CDN呈现的DDoS攻击的可行性。发现与使用的入口IP数量相比，CDN用于将请求转发到源的出口IP的数量较小，从而导致出口IP调度率低得多。因此提出了这样一种可能性，即可以利用较低的IP转换速率来有效降低CDN驱动的网站的全球可用性。

A.CDN进出口IP分配

确定给定CDN的入口和出口IP地址，可以直接从ICANN WHOIS数据库或某些CDN供应商提供的正式发布信息中找到CDN的IP地址。但是，WHOIS信息可能不完整或已过时（由于GDPR的数据最小化原则，许多欧洲注册商已停止为ICANN WHOIS数据库收集信息），并且正式发布的地址只是不分隔IP地址范围的IP地址范围。

由于需要深入分析CDN在接收最终用户请求时如何分配入口IP地址和出口IP地址，因此通过互联网范围的扫描探索入口IP分布，并通过向所有用户发送请求来揭示出口IP分布直接输入IP地址以模拟全球终端用户访问。

入口IP分配：通过将网站部署在CDN后面，互联网范围的HTTP扫描是一种收集入口IP的直接方法，通过它可以访问网站内容。首先使用Censys Internet HTTP扫描数据来过滤可能的入口IP。 Censys项目使用填充有扫描IP地址的Host标头扫描TCP端口80，并且CDN代理服务器在使用不正确的IP格式HTTP Host标头访问它们时，将返回独特的错误HTTP响应（标头或正文），如下表所示。

然后，将主机域名中的网站域名主动发送给这些过滤的IP，可以通过其访问源的IP被收集为入口IP。如表下中所示，发现了大量入口IP。

出口IP分配：对于实验，首先设置一个源服务器，该服务器将记录传入的出口IP和请求的URL。从客户端直接将请求发送到找到的所有入口IP。这些请求带有不同的查询字符串，以避免CDN的缓存命中，例如http://IngressIP1/i.php?IngressIP1 。然后，CDN通过不同的出口IP将这些请求转发到源服务器。最后，从源服务器上记录的数据中，收集出口IP并从URL查询字符串中提取相应的入口IP。

为了尽可能多地收集出口IP，每隔24小时向入口IP发送一次请求，并在源处记录结果数据。上表中显示了删除重复项后的出口IP数量以及它们的BGP前缀和ASes（由Route View Project 数据确定）。从上表可以看到，即使CDN具有大量的入口IP，CDN也会对传入的请求进行分组，并分配少量的出口IP，以将请求转发到源。还发现对于每个转发的请求，请求的出口IP与入口IP不同，例如在24小时范围内，通过CloudFront发送的请求中只有0.06％具有相同的入口/出口IP，其他CDN的相应百分比为Cloudflare为0％，Fastly为0.02％和MaxCDN为3.82％。

此外，在相同的24小时测量持续时间内，分析了出口IP搅动率（或发生率），它描述了CDN重复分配相同出口IP的频率。在上图（Y轴为对数比例）中，为简单起见仅绘制了前32个分配最多的出口IP 4的比率。从图中可以看到96.32％的MaxCDN请求来自一个单一的出口IP。换句话说，MaxCDN仅通过一个出口IP分配了大多数请求。另一方面，对于其他CDN，可以在图中看到它们的出口IP被更均匀或随机地分配，其中出口IP所收取的请求不超过10％。

源位置的影响：可以看到某些CDN分配了少量出口IP来访问源，并且不会很快搅动这些IP。为了验证源位置是否会影响攻击，换言之，MaxCDN分配的出口IP是否是源IP的功能，在位于新加坡硅谷、北京和新加坡的源服务器进行设置并进行了实验，并确定分配给这些不同位置的出口IP相同。

B.攻击面分析

CDN通过其大规模的地理分布代理服务器为网站提供全球可用性。如果攻击者想要停止或降低CDN支持的网站的全球可用性，最明显的方法是直接对源头发起DoS攻击。但是，如果没有相关的历史数据或信息的意外泄漏，则很难确定源IP地址。因此，为了尝试攻击方法，攻击者可以尝试入侵和控制某些路径上的网络基础结构（例如，路由器或防火墙），使其成为客户端CDN连接或CDN来源中的路径连接以阻止相关IP。

但是，由于CDN代理在全球范围内分布有大量IP地址，因此攻击者（甚至是国家级攻击者）不可能在所有客户端CDN连接或CDN源连接中都处于路径上。因此，在攻击者仅能阻止几个连接的前提下，通常，攻击不会影响网站的全球可用性。

在这里，如上图所示可视化了一个威胁模型，即攻击者只能切断一个或一小组CDN起源的连接，而攻击者的目标是降低CDN驱动的网站的全球可用性。认为这种威胁模型是切实可行的，因为它要求攻击者入侵并控制更少的路径上网络基础结构（例如路由器或防火墙），才能切断一个或一小套CDN源连接，否则攻击者可以发起交叉攻击，通过淹没CDN节点周围的网络链接来秘密地切断一个或一小群CDN节点的互联网连接。基于此威胁模型，进一步评估了全球可用性下降攻击的可行性和严重性。

C.真实攻击分析

实验设置：可以看到根据上图，降低以MaxCDN为动力的网站的可用性仅需要切断一个CDN源连接（即，阻止一个出口IP），而对于其他CDN，则需要切断更多的CDN。连接。

在实验中，在0小时将请求发送到给定CDN的所有入口IP，以模拟访问网站的全球客户，并获得成功请求的数量作为计算以下访问率的基础。

此后从小时1开始，将封锁分配最多的出口IP，以模拟切断CDN源连接（例如，交叉攻击）。对于MaxCDN，仅阻止一个路径防火墙中的一个出口IP，而对于其他CDN，阻止分配最多的16个出口IP。仍然每小时一次将请求重复发送到同一组入口IP，持续12小时，以模拟全球客户端的访问并记录成功访问率。请注意，所有请求均使用随机URL发送，以绕过CDN缓存。

实验结果：在图下中绘制了每小时访问率，由于MaxCDN仍将阻塞的IP分配给转发大多数请求，因此访问率在12小时内下降到不足10％。这种现象进一步表明，当其他出口IP仍可以访问源时，MaxCDN缺乏检测攻击的机制。

在上图可以看到其他CDN也缺少检测攻击的机制，例如，对于CloudFront，访问率在阻塞后波动约40％，而对于Cloudflare和Fastly，访问率波动约90％，这可能归因于其更快地制造出口IP的能力。

实际分析：由于源IP地址隐藏在CDN后面，因此不可能对源进行直接DoS攻击。假设攻击者（例如国家级）可以通过入侵路径上的网络基础设施（例如，路由器或防火墙）或发起交叉攻击攻击来阻止一个或一小套CDN源连接出口节点的互联网访问。在这里进一步揭示了在特定的网络情况下，普通攻击者如何能够轻松获得切断CDN来源连接的能力，从而使攻击更加实用。

众所周知，GFW将检查可能通过的HTTP连接。在HTTP连接中检测到任何敏感的禁止词（例如ultrasurf）后，GFW将注入TCP RST数据包以关闭该连接，并且GFW将将该HTTP连接中的IP对列入黑名单近90 s。在本文中，介绍了普通攻击者如何滥用GFW的能力来发起可用性降低攻击。

CDN仍支持CDN源连接中的纯文本HTTP协议，路径上的网络基础设施可以拦截该协议。如下图所示，当GFW已位于CDN与源之间的路径上时，攻击者可以故意发送HTTP GET请求以及GFW禁止的词，以激活GFW的连接重置机制。

这种机制导致CDN出口IP和源IP对被GFW阻止了90 s。在这90秒钟内，当普通客户端尝试访问该网站时，并且如果分配了相同的CDN出口IP来访问源，则GFW将继续重置随后的新TCP连接，即使没有GFW被禁止这些联系中的词。因此，普通客户将无法访问该网站，从而降低了来源的可用性。

此类降级的严重程度取决于可以将多少个CDN出口IP添加到GFW的黑名单中。正如已经说明的，攻击者可以轻松获取CDN入口IP，并将GFW禁止的请求连续发送到每个入口IP。根据CDN的出口IP分配策略，越来越多的CDN出口IP将被添加到GFW黑名单中。请注意，CDN会分配少量出口IP，从而进一步降低了此类攻击的门槛，因为将这些较少的出口IP添加到GFW黑名单中会消耗更少的时间。因此，当所有出口IP都被列入黑名单时，没有客户端将能够访问目标网站，从而导致源服务不可用。

为简单起见和出于道德考虑，进一步评估针对位于MaxCDN后面的位于中国的网站的攻击。由于GFW会重置发送到中国或从中国发送的TCP连接，并且出口IP都位于中国境外，因此在北京建立了一个网站，该网站部署在MaxCDN的后面。后来，从作为攻击者的Singa漏洞的优势出发，不断将GET / ultrasurf HTTP请求直接发送到之前找到的MaxCDN入口IP。

同时，从新加坡作为普通客户的另一个角度出发，发送GET/normal HTTP请求以验证该网站是否仍可访问。为了访问网站，MaxCDN分配的出口IP少于12个，而GFW可能会附带阻止该出口IP，在这种情况下，将使网站完全无法访问。由于GFW被滥用，当攻击通过中国以外的CDN进行访问时，攻击只会影响位于中国的源。但是，可以看到CDN的较低IP输出速率确实降低了攻击的难度。

总结：首先可以看到，与CDN通常使用的成千上万个入口IP相比，出口IP地址空间要小得多，这有助于攻击者缩小攻击目标的范围。其次，较低的IP传输速率降低了对CDN源连接的攻击难度，例如访问阻止（路径上阻止或路径外DoS攻击，例如“ CrossFire”攻击），流量窃听或查找通过历史网络流量的源服务器IP。因此认为，这一威胁可能比乍一看可能要严重得多。

 

0x06 Discussion

A.严重程度分析

在本文中使用六个CDN的实际测量结果表示可以利用这些CDN的操作和体系结构弱点来破坏这些CDN提供的DoS保护。对于以CDN为动力的网站，CDN建议源服务器强制执行防火墙白名单，以仅允许CDN发起的连接。因为源必须仅与更可信赖的CDN通信，所以源可以完全委托CDN进行DoS保护，而无需执行任何本地的反DoS机制。因此，当绕过CDN提供的DoS保护时，可能导致对源的更严重损害。

由于CDN供应商未验证来源的所有权，因此恶意CDN客户可以将任何其他网站配置为CDN背后的来源。因此，本文中的威胁也可以被滥用为不仅攻击已经在CDN中托管的网站，而且还会攻击那些不在CDN中托管的网站。安全团队在对披露的回应中也表达了同样的担忧。

B.原因和缓解

通常，威胁存在的部分原因是市场竞争。 CDN供应商自然希望提供更多功能，并与不同配置的客户网站实现最大的兼容性。但是，万维网生态系统同时受到网络和应用程序层威胁的威胁，因此，可以利用这些CDN提供的功能齐全的功能（带有协议缺陷或实施缺陷）来破坏CDN的安全性。

HTTP/2带宽放大攻击：该威胁来自CDN的HTTP/2半完成支持。默认情况下，许多CDN都打开了HTTP/2，这一威胁变得更加严重。假定此漏洞的原因是CDN供应商缺乏在CDN起源的连接中启用HTTP/2的动机。例如，Cloudflare指出“ HTTP/2协议现在专注于改善浏览器的行为，无需为启用HTTP/2而对源进行任何修改。”。另一个原因可能是HTTP/2仍未被互联网上的网站广泛部署。根据CloudFront的说法“仍然使用HTTP/1建立从CloudFront到源服务器的连接。您无需进行任何服务器端更改即可通过HTTP/2访问静态或动态内容。”

从根本上讲，HTTP/2规范在HTTP/1.1和HTTP/2共存环境中缺乏足够的安全考虑。同时，当CDN供应商急于支持HTTP/2以获得以效率为中心的功能时，这些CDN供应商仅在客户端CDN连接中支持HTTP/2，导致HTTP/2-HTTP/1.1转换环境不支持。在相关规范中明确定义。这两个因素导致HTTP/2威胁。因此认为CDN供应商在支持该新协议时应保持保守，而应将其作为“选择加入”选项。此外，如果打开HTTP/2，CDN供应商还应该进一步限制转换后的CDN起源的HTTP/1.1连接。

Pre-POST HTTP攻击：通常，CDN将传统的客户端与网站的连接分离为客户端CDN和CDN起源的连接，这种设置自然可以抵御来自客户端的缓慢的HTTP攻击。但是，某些CDN的Pre-POST转发行为使攻击者能够控制后端CDN起源的连接。

Pre-POST威胁利用了某些CDN供应商的意图来加快POST转发的速度，同时引入了新的攻击媒介。研究表明，已检查的六个CDN中有三个容易受到威胁。最明显的缓解方法是，网站管理员可以在源端实施超时，尽管此解决方法需要在每个由CDN驱动的网站上进行配置。建议CDN供应商实施更严格的POST转发机制，例如Cloudflare已应用的store-then-forward。

全球可用性下降攻击：CDN的出口IP分配策略绝对取决于实现。根据测量，某些CDN供应商的出口IP分配策略是可以预测的。尤其是，MaxCDN可以通过相同的出口IP分配大多数全球请求，即使源位于不同的区域也是如此。因此，对于攻击者来说，降低全球可用性的攻击变得更加实际，要求切断或阻止更少的CDN起源连接。

这种威胁利用了CDN的重点，即以更少的IP资源有效地访问Web资源，即更有效地访问和缓存），从而使全球可用性降低攻击更易于执行。因此，为了提供更强大的网络服务，建议CDN供应商将其出口IP分配策略调整为更加不可预测，例如通过分配更多出口IP并频繁地对其进行搅动。

总结：这三种威胁的存在揭示了CDN对可用性和效率的追求，同时显然忽略了安全性。总体而言，建议在下表中列出以下CDN方面的缓解措施。

此外，由于证明CDN转发的请求可能被滥用来攻击网站服务器，因此也建议网站服务器实施本地DoS防御，例如请求过滤或带宽限制，即使这些网站服务器部署在可信赖的CDN后面。

 

0x07 Conclusion

CDN已成为互联网不可缺少的一部分，除其他好处外，它还为CDN驱动的网站提供了反DoS服务。但是，通过利用其体系结构、实施或操作上的弱点，CDN本身也可以用来破坏CDN DoS保护。

通过揭示三个相关威胁并提供六个CDN的真实测量，本文揭示了CDN供应商在安全性和可用性之间做出的有缺陷的取舍。由于协议或实施方面的弱点，可以滥用CDN中功能齐全的HTTP转发支持来对源网站发起有效的DoS攻击。希望本文工作能够促使CDN提高其安全标准，并激励更多的研究人员探索CDN相关的安全性。