长话短说

Zafran的研究团队发现了Akamai、Cloudflare、Fastly、Imperva等公司在流行的网络应用防火墙（WAF）服务实施过程中存在的一个普遍的错误配置漏洞。受影响的WAF供应商负责保护全球90%的网络应用程序。（证明来源：https://w3techs.com/technologies/overview/proxy ）

该错误配置可能会让威胁行为者绕过WAF保护，直接通过互联网针对网络应用程序和负载均衡器发起攻击。攻击者借此可能会对暴露的网络应用程序进行分布式拒绝服务（DDoS）攻击，或者利用应用程序本身存在的、原本会被WAF识别或拦截的漏洞进行攻击。这种错误配置源于同时充当内容分发网络（CDN）提供商的WAF提供商的架构弱点。在此类CDN/WAF服务的架构中，受保护的网络应用程序被指示验证路由到它们的互联网流量是否来自CDN/WAF提供商，若未能如此验证，就可能导致上述绕过情况的发生。

为评估此类错误配置的普遍性，本研究着重对大量域名样本——《财富》1000强企业的域名进行评估。

我们首先确定了70万个域名，这些域名能够对应到《财富》1000强企业中的约700家。通过互联网全域扫描以及新颖的指纹识别技术相结合的方式，我们识别出超过14万个受CDN/WAF提供商保护的域名。从中，我们又能将8000个域名对应到3.6万个可通过互联网直接访问的后端服务器，因此这些服务器也就暴露于DDoS攻击之下。这些研究结果证明了该错误配置的普遍性，因为受影响的域名分布在很高比例的《财富》1000强企业中（我们最初的样本集）。受影响的域名分属于近40%的《财富》100强企业以及20%的《财富》1000强企业。

背景——什么是内容分发网络（CDN）？

与传统的负载均衡器和网络应用防火墙（WAF）不同，传统的负载均衡器和WAF是作为物理或虚拟应用程序部署在客户场所内的，而内容分发网络（CDN）被设计成一个由众多互联网服务器组成的大型网络，它在靠近边缘（靠近终端用户）的位置处理网络流量，并最终通过互联网将流量路由到网络应用程序。如今，大多数网络应用程序不会将其前端服务器直接暴露在互联网上，通常会在自己的服务器前使用CDN服务。

有许多公司提供CDN服务，其中最受欢迎的是Akamai、Cloudflare、Fastly和Imperva。CDN的主要功能是在不同的地理位置设立数据中心，以便为客户网络应用程序的静态内容提供更低的延迟和更高的下载速度。

然而，虽然这些公司的主要服务是CDN，但它们也提供防护功能，客户可以选择激活（或不激活）这些功能。这些防护功能通常包括：

DDoS防护：DDoS防护功能用于在边缘网络位置阻止拒绝服务（DoS）流量，在其有机会触及实际的前端服务器之前就将其拦截。CDN提供商在整个网络中收集有关可疑IP的情报，用验证码（CAPTCHA）对可疑请求进行验证，当判定请求为恶意时则阻止流量。
网络应用防火墙（WAF）防护：WAF功能用于在边缘网络对请求进行过滤，在请求有机会触及客户的服务器之前就将其拦截。这些功能传统上会搜索常见网络攻击类型（如跨站脚本攻击（XSS）、SQL注入（SQLi）、服务器端请求伪造（SSRF）等）的模式。它们还可以包含检测或拦截新出现的关键通用漏洞披露（CVE）利用行为的规则。

绕过CDN/WAF——它是如何运作的？

CDN通常针对域名或子域名按以下方式进行配置：

客户域名的DNS A记录将流量导向CDN边缘网络内的反向代理服务器。这种设置可以通过使用CNAME记录或者将NS记录更新为CDN服务提供的DNS服务器来实现。
反向代理从传入请求的TLS服务器名称指示（SNI）字段（如果未使用TLS，则从HTTP主机头）中读取目标域名。在向CDN提供商配置域名时，客户需提供有效的TLS证书和密钥，以便CDN提供商管理外部TLS握手。
然后，反向代理应用CDN逻辑，可能会提供缓存的静态内容，并将任何剩余请求转发到客户为该域名指定的源服务器。在整个过程中，源服务器（通常是客户网络应用程序的前端服务器）的IP地址和端口对用户来说是隐藏的，它们被视为CDN/WAF网络架构中的“秘密”部分。

反向代理与源服务器之间的通信也需要进行TLS加密。不过，要使用的证书类型由客户选择，因为——CDN提供商支持多种选项。

更重要的是，如果源服务器的IP地址/端口泄露了，攻击者现在就可以直接针对源服务器发起攻击，从而完全绕过CDN的保护。

CDN/WAF绕过的缓解措施

为缓解这一问题，除了对源服务器IP地址保密之外，CDN提供商推荐了一些最佳实践，通常包括以下步骤：

在源服务器的防火墙为传入连接添加IP过滤，只允许CDN提供商的IP范围向源服务器发起请求。
使用自定义的HTTP头，其中包含一个预共享密钥，该密钥只有CDN和源服务器知晓，由CDN设置并由源服务器进行验证。
在反向代理和源服务器之间使用双向TLS认证（mTLS）。客户将在其源服务器上配置一个用于客户端证书验证的证书颁发机构（CA）。该CA由CDN服务提供，但客户有责任确保源服务器对客户端证书进行验证。
Cloudflare将此称为源站认证回源（Authenticated Origin Pulls），并且在代理和源服务器之间的TLS连接可能会使用“Cloudflare源服务器证书”选项。

虽然上述缓解措施通常是不错的解决方案，但先前的研究表明，在某些情况下，这些方法也可能被绕过。例如，已经证实，通过创建一个由攻击者控制的Cloudflare账户，将其配置为与受害者指向相同的源服务器，攻击者就可以伪装成“Cloudflare”——利用Cloudflare的IP地址和Cloudflare证书来访问受害者的源服务器。同时，攻击者可以控制恶意账户上的DoS和WAF保护设置，并直接将其关闭。使用带有预共享密钥的自定义HTTP头可以规避这种复杂的绕过手段。

无论如何，需要强调的是，防止攻击者直接与源服务器通信的额外缓解措施，取决于客户需要在每个源服务器上实施的配置变更。不出所料，我们的扫描结果显示，这些措施很少被实施，如下文所示。因此，这使得源服务器IP/端口的保密性成为抵御此类绕过行为的首要（且可能是唯一的）防线。

Cloudflare源证书颁发机构（Origin CA）

一个有趣的细节是Cloudflare针对源服务器TLS连接使用由Cloudflare颁发的源服务器证书这一选项。

显然，Censys发现互联网上有超过20万个主机响应时使用了此证书。这意味着，这些都是暴露的源服务器，攻击者可以发现它们并能够直接与之通信，除非使用了mTLS缓解措施。

在对1000个此类开放了443端口的源服务器进行随机抽样后发现，总共有780个服务器提供了成功的响应状态码。只有130个服务器返回了400、403或TLS握手错误，这些情况可能是由于mTLS验证失败导致的。因此，似乎只有约13%的这些源服务器实施了源站认证回源（Authenticated Origin Pulls），尽管这个数字可能还高估了（出现这些HTTP错误码可能还有其他原因）。

在互联网上扫描“突破WAF”漏洞暴露情况

如前文所述，为评估上述CDN/WAF绕过情况的普遍性，本研究着重对大量域名样本——《财富》1000强企业的域名进行评估。首要任务就是收集《财富》1000强企业所拥有的所有域名列表。

域名收集

攻击者和安全研究人员有多种方法来发现属于目标组织的域名，这是在评估开始时可以采取的常规侦察步骤的一部分。其中最好且最简单的方法之一，就是使用证书透明度（Certificate Transparency，CT）日志。

像Censys这样的公司提供对CT日志的访问权限，https://crt.sh这个免费（但速度较慢）的服务也可以。如今，每当浏览器信任的证书颁发机构（CA）颁发证书时，就会生成一个CT日志。它们原本是为了让域名所有者能够察觉到以他们名义颁发的恶意证书而设计的。然而，像crt.sh这样的服务会监听这些CT日志，并将它们永久存储。这使得你能够发现像IBM这样的组织的域名，因为字符串“IBM”会出现在其颁发证书的主题（Subject）字段中：

此外，人们可以针对包含某些公司域名（如“IBM”）的域名查询crt.sh返回的结果，收集属于该组织的唯一二级域名，然后递归查询二级域名下的其他子域名。这样可以发现更多域名，因为TLS证书在每个证书中可以有多个主题备用名称（Subject Alternative Names，SANs）。SANs是证书有效的其他域名列表。现在可以利用它将域名与其他域名关联起来，因为单个证书不太可能拥有属于不同组织的主题备用名称。几乎总是单个组织拥有单个证书中的所有域名。

解析和分类《财富》1000强企业域名

由于我们希望发现属于《财富》1000强企业的所有与CDN相关的域名，在手头有了大量域名列表后，我们现在需要检查每个域名，并对该域名是否指向CDN服务器以及指向哪个CDN服务器进行分类。

我们确定了几种识别和分类指向CDN服务器的域名的技术：

通过域名系统（DNS）解析域名，并检查IP地址的自治系统编号（ASN，即IP范围的名称）是否归属于CDN提供商（并非CDN的所有ASN都归其提供商所有，但很多是这样的）。
以其他方式利用域名的DNS解析结果——例如，可以查看CNAME链中域名的子字符串（比如下面针对images.jpmorganchase.com的dig示例中的*.akamaiedge.net ）。
向疑似的CDN服务器发送HTTP请求，并对其响应进行指纹识别。

上述第三种方法产生了最有效的指纹识别技术，该指纹识别技术将在下一节详细介绍。上述指纹识别技术得出了一个大约70万个成功解析的域名列表，其中14万个与CDN相关。对于每个相关域名，都记录并分类了对应的CDN提供商标识符。

需要注意的是，最初从CT日志获取域名时，也包含了大量的“无效域名”。所谓“无效”，是指这些域名实际上并不属于它们被发现所对应的组织。不过，在这个发现阶段之后，会有多个针对域名的验证步骤，这些步骤会大量过滤掉这些“无效”域名。

通过HTTP请求对CDN服务器进行指纹识别

如前文所述，我们发现的对CDN服务器进行指纹识别的最有效技术是观察疑似服务器对HTTP请求的响应。首先让我们来看一个与CDN相关的域名（images.jpmorganchase.com，由Akamai保护）的域名解析情况：

当向一个与CDN相关的域名发送请求时，对用户来说通常是相当透明的操作。请求会在边缘（在CDN服务器处）进行处理，或者被代理到后端的源服务器（例如在API请求的情况下）。因此，要判断A记录是否指向CDN代理可能会有点困难。然而，对于Akamai或Cloudflare来说，相同的代理服务器会被用于许多不同的域名。举例说明：

那么Akamai代理服务器如何知道请求的主机名/域名呢，如果两个请求都到达同一台服务器的话？

在TLS连接中，“TLS服务器名称指示（SNI）”字段应出现在客户端“Hello”消息中。代理服务器将利用该字段从其客户配置数据库中获取匹配的服务器证书，然后将流量转发到匹配的源服务器。
在普通的HTTP连接中，主机（Host）头用于相同目的。

因此，如果向CDN代理服务器发送一个没有SNI或Host头的请求，它会表现出一种特殊的行为，并且这种行为是可以被识别出来的：

虽然常规（非代理）服务器也可能依赖 TLS SNI 来了解要提供哪个证书，但对同一 IP 的纯 HTTP 请求却会暴露身份。例如，通过向 cloud.oracle.com 的 A 记录 IP 发出此类请求，我们可以确定它使用 Akamai。

扫描IPv4网络（使用zmap和zgrab2工具）

手头有了与CDN相关的域名列表后，我们现在需要实际找出为这些相同域名提供服务的直接暴露的源服务器。

如前所述，CDN服务器使用TLS-SNI标头根据该标头中的服务器名称来路由请求。然而，典型的前端服务器，甚至是负载均衡器（LB），通常属于单个应用程序或组织，一般不需要处理SNI标头。在这类服务器上配置TLS证书的简单且合理的方式有以下两种：

用单个TLS证书来处理所有请求，该证书的主题备用名称（SANs）涵盖所有使用的域名。
根据SNI选择使用多个证书，其中一个作为默认证书。

在这两种常见情况下，直接向前端服务器的IP地址发送一个不带任何SNI的HTTPS请求，将会呈现给我们一个默认的服务器证书。这个证书将揭示该服务器正在服务哪些域名。

我们选择了一种简单的方法，只扫描端口443上的TLS证书，因为扫描非标准端口可能会很耗时。这意味着下面的结果实际上只代表了WAF绕过问题全部范围的一个子集，因为许多源服务器可能绑定到非标准端口上。

这次扫描就是对所有互联网IPv4地址进行抽样，查看端口443是否开放的常规扫描。扫描结果大约有4500万个服务器，这与Censys的估计接近。

之后，使用zgrab2工具获取所有这些服务器提供的TLS证书：

在对获取到的TLS证书进行处理后，可以将它们精简到大约4500万个如下所示的条目：

将域名与服务器进行匹配

此时，我们可以将14万个与CDN相关的域名与新获取到的4500万个互联网服务器进行匹配。匹配过程是通过比较域名来进行的，同时也要考虑到主题备用名称（SANs）中可能出现的通配符情况。

这次初始映射得出了3.6万个匹配的服务器，涉及8100个《财富》1000强相关的唯一域名！这3.6万个匹配项中的每一个都可能是属于《财富》1000强企业的可直接访问的源服务器。这些数字相当可观，但其中确实包含了误报情况。还需要执行额外的验证和过滤步骤，比如：

根据自治系统编号（ASN）（如“CLOUDFLARENET”、“Akamai International”等）确认服务器IP实际上不是CDN的IP地址。
通过向服务器IP发送HTTP请求，确认返回的服务器头不是CDN服务器名称（如“AkamaiGHost”、“Cloudflare”等）。

此时，就剩下最后的验证步骤了。对于每个域名/源服务器对，我们需要比较来自CDN服务器的HTTP响应和针对同一域名新发现的源服务器的响应。这样可以确保从这两个位置提供的是同一个网络应用程序，从而极有可能确认我们发现了一个绕过漏洞。

在上述示例中，展示了一个绕过漏洞的发现情况。向CDN和新发现的源服务器发送请求后，二者都返回了看似相同的网页。域名agreements.apple.com解析到一个Akamai的CDN代理服务器（其ASN是“AKAMAI-AS”），而IP地址为17.32.214.239的服务器属于“APPLE-ENGINEERING”这个ASN，并返回了一个“Apple”服务器头。

上述方法通过一个验证脚本来实现自动化，该脚本执行以下步骤：

验证两个请求的HTTP状态码没有差异，或者是等效的。
如果响应有正文内容，进行文本差异对比，确保正文内容90%是相同的（有时CDN会向页面注入脚本）。
某些HTTP头，如内容安全策略（Content-Security-Policy）和位置（Location）等可能很有指示性。它们通常包含域名和URL，这些信息可能足够独特，能够判断响应是否相同（针对没有正文内容可供比较的响应情况）。
比较Cookie的名称，比如上述示例中的JSESSIONID、SA_SESSIONID等。Cookie名称集合也可能足够独特，可用于确认响应是否匹配。
尽量忽略除404之外的大多数错误响应。例如，如果两个响应都是403，且正文文本匹配度不强，就不应将它们视为等效的。这样做是为了避免误报，比如在受mTLS保护的服务器的情况下。

研究发现

在对数据进行映射、验证和清理之后，我们发现了一些关于《财富》1000强企业在WAF绕过错误配置方面存在的漏洞的有趣结果。

在《财富》1000强企业中，我们已经将670家企业的域名进行了映射。针对这些企业，确定了2367个暴露的源服务器。在它们当中，属于135家不同的《财富》1000强企业的2028个域名经高度确信评估，至少有一个受影响的域名/服务器。

值得注意的是，WAF绕过漏洞似乎尤其让《财富》1000强榜单前列的大型企业担忧。例如，榜单前100家企业占潜在受影响企业的35%。同样，年收入超过500亿美元的企业在受影响的组织中占比过高。

从受影响企业所属行业来看，金融服务行业最为普遍，占所有受影响企业的三分之一以上。

此外，我们的研究结果显示，Akamai的CDN可能比其竞争对手（如Cloudflare等）受到的影响稍大一些：虽然Akamai在《财富》1000强企业运营的与CDN相关的域名中仅占42%（至少是我们已经能够识别和映射的14万个域名），但在受WAF绕过错误配置影响的企业中却占59%。这并不意味着Akamai本身就比其他CDN更脆弱——只是使用Akamai的企业相对来说更容易“忽略”缓解这一风险。

值得注意的发现

以下是一些被发现受到“突破WAF”绕过漏洞影响的值得关注的域名列表：

假阴性情况

虽然上述结果看起来很显著，但许多潜在的暴露源服务器的情况并未包含在此次分析中：

有300多家企业未被包含进来，因为我们没能自动找到它们的域名。
非标准端口（非443端口）没有进行扫描。这一点尤其重要，因为我们认为，即便不是大多数，也有相当数量的源服务器会使用非标准端口。
仅支持IPv6的服务器未包含在我们的互联网全域扫描范围内，而在CDN代理（通过IPv4向用户提供服务）后面使用仅支持IPv6的源服务器正变得越来越常见。

假阳性情况

即使在经过自动验证得出2300个暴露服务器的列表之后，这些服务器中仍有可能存在一些假阳性情况。在我们的手动分析中，观察到了以下一些情况：

“专用”的Akamai代理服务器，它们看起来像是Akamai服务器，但只为一个大型客户服务，比如美国的一些大型银行。这些服务器的IP地址可能属于客户的ASN，很难自动进行分类。
一些大型企业的域名，其A记录指向的IP地址属于像“AKAMAI-AS”这样的ASN，但从其他方面看又不像是Akamai服务器。虽然它们仍有可能是，但这可能是一些定制的“大型客户”设置，同样很难识别和分类。

虽然我们不清楚上述潜在假阳性情况的范围，但它们不太可能超过数量更为显著的假阴性情况。

DoS和DDoS攻击的实际情况

为评估上述绕过技术的潜在影响，让我们来看看流行的CDN提供商提供了哪些拒绝服务（DoS）防护措施：

从各CDN提供商的文档中，我们可以了解到它们的服务能为客户提供哪些优势：

高容量：它们的边缘网络由于规模大和地理分布广，能够承受极高流量的DDoS攻击。
本地化的DDoS/DoS防范规则（在上图中被称为“dosd”）。这实际上与传统解决方案所能做的类似。不过，它们的服务得益于对实际流量模式和攻击情况的熟悉，因为它们几乎能持续看到整个网络的情况。
全局的DDoS防范规则和特征签名。这是关键优势所在。全局规则能够根据实时事件和情报生成。由于它们保护的网站数量众多，能够收集大量情报。

基本上，大型CDN提供商对网络上的大量流量有着广泛的监控能力。此外，它们能够以在边缘网络内应用新规则的形式立即采取行动。这使得它们即使不能立即缓解，也能在相对较短的时间内应对规模最大的DDoS攻击。

Linux服务器上的本地DoS防护

如果有人选择不为自己的服务器使用专门的DDoS防护措施，那么对于标准的Linux/nginx服务器来说，在抵御攻击方面能有怎样的预期呢？有几个为此目的而设计的功能：

内核SYN洪水防护：这是一种经典的传输层DoS攻击。在内核层面通过“SYN cookies”来缓解这种攻击。但它对任何应用层DoS攻击或能够控制大量IP地址的攻击者都不起作用。
Iptables速率限制：可以在防火墙层面对IP块进行速率限制。但这种配置很难手动设置正确，而且还容易影响正常用户体验。依赖它并不现实。
Nginx连接速率限制：比在防火墙层面要好一些，但仍然需要应用程序设计者非常谨慎地考虑速率限制问题。
Fail2ban：这是一个查看流量日志并动态封禁行为不当或对服务器发起DoS攻击的IP地址的应用程序。它在应对少量源IP发起的DoS攻击时效果还不错。然而，它不太可能应对来自大量IP池的大规模DDoS攻击。

值得注意的是，对于默认配置且未预料到会遭受DoS攻击的Linux/nginx服务器来说，几乎没有什么防护措施。那些期望由CDN提供保护的源服务器不太可能运行Fail2ban或实施任何自定义防护措施。因此，如果被直接攻击，它们很容易受到DoS攻击的影响。

有害的服务器配置

一些在典型Linux服务器上常见的配置甚至可能对DoS抵御能力产生不利影响。为说明这一点以及上述相关内容，考虑以下一个典型的iptables配置示例：

这里的问题在于允许已建立连接通过防火墙的连接跟踪（conntrack）规则。首先，对于这个配置来说，这一行是不必要的。由于输出（OUTPUT）策略是允许（ACCEPT），它不会产生任何影响，因为无论如何都不会阻止任何外出流量。其次，连接跟踪（conntrack）在内核中有一些限制，具体来说：

默认情况下，被跟踪的连接数量可能会被限制在一个非常低的值！在这个极端的例子中，单个IP的DoS节点就可以打开1.5万个连接。一旦达到这个被跟踪连接的数量，内核就会开始丢弃合法连接，从而导致严重的拒绝服务（DoS）情况出现。

对真实源服务器的DoS测试

我们已经有了经过验证的、可直接访问的源服务器及其对应的与CDN相关的域名列表。为了动态验证我们的结果，我们决定在短时间内对一些受影响的服务器谨慎地进行拒绝服务（DoS）攻击，同时通过CDN来测量对与CDN相关的域名的影响。如果在对源服务器进行DoS攻击时，通过CDN能测量到影响，那么就百分百确认存在绕过情况了。

我们选择的DoS方法是通过使用zgrab2工具从单个IP向目标服务器建立大量的TLS连接，尝试耗尽目标服务器的CPU和连接池。在直接向源服务器IP发起DoS的TLS连接时，测量连接则是通过CDN向真实的与CDN相关的域名发起，就如同普通用户进行连接一样。

测量是从位于不同地区、有着不同IP的另一台测量机器上进行的。
实际测量的指标仅仅是一个完整的HTTPS请求的往返时间（RTT，即延迟）。

重要的是，在每个服务器上选择的测试端点类似于“/dummy1234”，其中的数字是随机且每次请求都唯一的。这样能确保CDN每次都必须将请求转发到源服务器。就往返时间（RTT）而言，404响应受到的影响应该和200响应是一样的。

测量结果

上述结果是相当明显的。往返时间（RTT）测量的超时设置为1秒。因此，最后3种情况更有可能是由某种连接池耗尽问题导致的，比如上文讨论的连接跟踪（conntrack）问题。

上述测试呈现的是所发现的绕过漏洞的“最坏情况”，因为被攻击的目标服务器是单个IP，要处理某个网络应用程序的所有流量。尽管如此，网络应用程序由少数几个服务器来保护是很常见的情况，所以攻击者只需按线性方式扩大攻击范围就行。一个组织有序的攻击者还可以创建僵尸网络，利用数万台机器的带宽、地理位置和CPU资源，来发动简单却更强大的DDoS攻击，即便针对的是最大规模的网络应用程序设置（在绕过CDN的情况下）。

最后，我们对一个BHHC域名进行了类似的DoS测试，并展示了用户访问该域名时会如何受到此类攻击的影响。