使用NGINX App Protect DoS保护gRPC应用，抵御严重的DoS攻击

NGINX | 2022年2月10日

Thelen Blum高级产品营销经理，NGINX App Protect | F5

过去两年，客户对商品和服务的需求凸显了轻松扩展和加快创新对组织的重要性，促使许多组织加速从单体架构转向云原生架构。根据F5近期发布的报告《2021年应用策略现状》，仅去年一年，开展应用现代化改造的组织数量就增长了133%。云应用采用模块化和分布式设计，并以自动化方式部署和管理。虽然可以直接将现有单体应用迁移到云端，但这种方式在成本或灵活性方面并无优势。要充分利用云计算服务所提供的分布式模式，更有效的方式是采用模块化思维，也就是引入微服务。

微服务是一种架构方法，开发人员可借此将应用构建为一组轻量级应用服务，这些服务在结构上彼此独立，也不依赖底层平台。每个微服务都作为独立进程运行，并通过定义明确且标准化的API与其他服务通信。每项服务均可由小型独立团队开发和部署。这种灵活性有助于组织在性能、成本、可扩展性和快速创新能力方面获得更大优势。

开发人员一直在寻找提高效率和加快应用部署的方法。API支持软件之间的通信，并为开发提供构建模块。为了使用HTTP向服务器请求数据，Web开发人员最初使用SOAP，它通过XML文档发送请求的详细信息。然而，XML文档通常较大，会产生大量开销，并且开发耗时较长。

此后，许多开发人员转而采用REST。这是一种用于创建无状态、可靠Web API的架构风格和一套准则。遵循这些准则的Web API称为RESTful API。RESTful Web API通常基于HTTP方法，通过URL编码参数访问资源，并使用JSON或XML传输数据。使用RESTful API可以加快应用开发速度，并减少开销。

技术进步为改进应用设计带来了新的机遇。2015年，Google开发了Google Remote Procedure Call（gRPC），这是一种可在任何环境中运行的现代开源RPC框架。REST基于HTTP 1.1协议并采用请求-响应通信模型，而gRPC使用HTTP/2进行传输，并采用客户端-响应通信模型。其实现使用协议缓冲区（protobuf）作为描述服务和数据的接口描述语言（IDL）。Protobuf用于序列化结构化数据，设计注重简洁性和性能。得益于protobuf的高效性以及对HTTP/2的使用，gRPC接收数据的速度约为REST的7倍，发送数据的速度约为REST的10倍。gRPC还支持流式通信，并可同时处理多个请求。

gRPC具有低延迟、支持多种语言、数据表示紧凑和实时流式传输等特点，因此开发人员认为，使用gRPC构建微服务是RESTful API之外颇具吸引力的选择。gRPC尤其适合微服务之间的通信，以及通过低功耗、低带宽网络进行通信。gRPC日益普及，因为它有助于更快速、高效地构建新服务，同时提高可靠性和可扩展性，并使客户端和服务器均不受编程语言限制。

尽管gRPC协议的开放性带来了多项优势，但该标准无法保护应用免受DoS攻击的影响。gRPC应用仍可能遭受与传统应用相同类型的DoS攻击。

为何难以识别针对gRPC应用的DoS攻击

微服务和容器让开发人员拥有更大的自由度和自主权，能够快速向客户发布新功能，但也带来了新的漏洞和可利用机会。拒绝服务（DoS）攻击是日益常见的一类网络攻击。近年来，由此产生的常见漏洞与披露（CVE）数量不断增加，其中许多是由于未正确处理gRPC请求所致。近年来，针对应用和API的第7层DoS攻击数量激增20%，其影响范围和严重程度则上升了近200%。

DoS攻击通常会发送大量看似合法的流量，以耗尽应用资源，使其无法响应。在典型的DoS攻击中，恶意攻击者会向网站或应用发送海量流量，使服务器因请求过多而不堪重负，进而停滞甚至崩溃。DoS攻击旨在降低计算机或网络的运行速度，或使其完全瘫痪，导致需要使用它们的人员无法访问。在攻击得到缓解之前，依赖相关计算机或网络的服务（例如电子商务网站、电子邮件和在线账户）将无法使用。

我们发现，越来越多的DoS攻击利用HTTP和HTTP/2请求或API调用来攻击应用层（第7层）。这主要是因为第7层攻击可以绕过并非针对现代应用架构而设计的传统防御措施。为什么攻击者从针对网络层（第3层和第4层）的传统大流量攻击转向第7层攻击？因为他们会选择阻力最小的攻击路径。基础设施工程师多年来一直在构建有效抵御第3层和第4层攻击的机制，使这类攻击更容易被阻止，成功的可能性也更低。因此，发起这类攻击需要投入更多资金和时间，攻击者便转向了其他攻击方式。

检测针对gRPC应用的DoS攻击极其困难，在自动横向扩展的现代环境中尤其如此。gRPC服务可能并非为处理大流量而设计，因此攻击者很容易将其击垮。gRPC服务也容易遭受使用h2load等工具发起的HTTP/2洪泛攻击。此外，攻击者利用protobuf规范中正确定义的数据定义时，也很容易以gRPC服务为攻击目标。

gRPC服务的一种典型误用情况是，脚本中的错误导致其向服务发送过多请求，尽管这种误用并非有意为之。例如，假设某个自动化脚本会在特定条件出现时发出API调用，而设计人员预计该条件每2秒出现一次。但由于条件定义有误，脚本每2毫秒就会发出一次调用，给后端gRPC服务造成意外负担。

针对gRPC应用的其他DoS攻击示例包括：

在gRPC消息中插入恶意字段可能会导致应用程序发生故障。
慢速POST攻击会在gRPC标头中发送不完整的请求。应用或服务器因等待请求的其余部分到达而保持连接打开。并发连接池可能会被占满，导致客户端后续的连接尝试遭到拒绝。
HTTP/2设置洪泛攻击（CVE-2019-9515）是指攻击者向gRPC协议发送空的SETTING帧，消耗NGINX资源，使其无法处理新请求。

充分发挥动态用户和站点行为分析的作用，借助 NGINX App Protect DoS 缓解 gRPC DoS 攻击

要保护应用免受当前DoS攻击，需要采用现代化方法。对于复杂且不断调整的应用，需要一种基于用户和站点行为提供高精度动态防护的解决方案，既能减轻安全团队的负担，又能支持快速开发应用并保持竞争优势。

F5 NGINX App Protect DoS是适用于NGINX Plus的轻量级软件模块，基于F5成熟的WAF和行为防护技术构建。NGINX App Protect DoS旨在抵御复杂的第7层DoS攻击，采用独特算法创建动态统计模型，提供自适应机器学习和自动防护。它持续衡量缓解措施的有效性，根据用户和站点行为的变化进行调整，并主动执行服务器运行状况检查。有关详细信息，请参阅博客文章NGINX App Protect拒绝服务防护如何适应不断变化的攻击形势。

传统HTTP应用和现代HTTP/2应用标头均支持行为分析。NGINX App Protect DoS基于签名和恶意行为者识别来缓解攻击。在初始签名缓解阶段，NGINX App Protect DoS会分析与异常行为相关的属性，创建动态签名，随后阻止与此行为匹配的请求。如果攻击持续，NGINX App Protect DoS将进入恶意行为者缓解阶段。

NGINX App Protect DoS基于统计异常检测，通过源IP地址和TLS指纹识别恶意行为者，并生成和部署动态签名，自动识别和缓解具有这些特定模式的攻击流量。这种方法不同于市面上传统的DoS解决方案，后者仅在流量超过阈值时检测攻击。即使请求看起来完全合法，且每个攻击者产生的流量甚至可能低于普通合法用户的平均流量，NGINX App Protect DoS也能阻止此类攻击。

以下Kibana仪表板展示了NGINX App Protect DoS如何快速自动检测并缓解针对gRPC应用的DoS洪水攻击。

图1显示一个gRPC应用正在遭受DoS洪泛攻击。在gRPC环境中，关键指标是每秒数据报数（DPS），对应每秒消息数。在此图中，黄色曲线表示学习过程：当基准 DPS预测值逐渐趋近传入 DPS值（蓝色）时，NGINX App Protect已了解该应用的“正常”流量模式。DPS在12:25:00急剧上升，表明攻击开始。红色警铃表示NGINX App Protect DoS确认攻击正在进行并开始进入缓解阶段的时间点。

图1：遭受DoS攻击的gRPC应用

图2显示了NGINX App Protect DoS使用分阶段缓解方法检测异常行为并阻止gRPC DoS洪泛攻击的过程。红色峰值表示在全局速率缓解阶段向所有客户端发送的HTTP/2重定向数量。紫色图线表示当特定客户端的请求与用于描述异常行为的特征签名匹配时，向这些客户端发送的重定向。黄色图线表示向检测到的特定恶意行为者发送的重定向，这些恶意行为者通过IP地址和TLS指纹识别。

图2：NGINX App Protect DoS采用分阶段缓解方法抵御gRPC DoS洪泛攻击

图3展示了NGINX App Protect DoS创建的动态签名。该签名由机器学习提供支持，可分析此次gRPC洪水攻击中与异常行为相关的属性。在初始签名缓解阶段，该签名会阻止与其匹配的请求。

图 3：动态签名

图4展示了攻击持续时，NGINX App Protect DoS如何从基于签名的缓解方式转为针对恶意行为者的缓解方式。通过分析用户行为，NGINX App Protect DoS已根据此处所示的源IP地址和TLS指纹识别出恶意行为者。此时，系统不再检查每个请求中是否存在表明异常行为的特定签名，而是拒绝向特定攻击者提供服务。这样便可生成动态签名，用于识别这些特定攻击模式并自动缓解攻击。

图4： NGINX App Protect DoS通过IP地址和TLS指纹识别恶意行为者

对于gRPC API，可通过gRPC接口在类型库（IDL）文件和protobuf的proto定义文件中设置安全策略。这提供了一种零接触式安全策略解决方案，无需依赖protobuf定义即可保护gRPC服务免受攻击。gRPC proto文件通常用于CI/CD流水线，通过自动实施保护并支持安全即代码，使安全团队与开发团队保持协同，实现与整个CI/CD流水线的集成。NGINX App Protect DoS将保护功能无缝集成到gRPC应用中，确保一致的安全性，使应用始终受到最新安全策略的保护。

gRPC为开发人员设计和部署现代应用提供了所需的速度和灵活性，但其框架固有的开放性也使其极易受到DoS攻击。严重的第7层DoS攻击可能导致性能下降、应用和网站中断、收入损失，并损害客户忠诚度和品牌声誉。要提前防范此类攻击，需要采用现代化防御方案。因此，NGINX App Protect DoS对于现代gRPC应用至关重要。

要亲自试用搭配NGINX Plus的NGINX App Protect DoS，请立即开始30天免费试用，或联系我们，讨论您的用例。