使用 NGINX App Protect DoS 保护您的 gRPC 应用免受严重 DoS 攻击

过去两年来，客户对商品和服务的需求凸显了企业轻松扩展和更快创新的重要性，这促使许多企业加速从单一架构向云原生架构的转变。 根据 F5 最近的报告《2021 年应用战略状况》 ，仅去年一年，实现应用现代化的组织数量就增加了 133%。 支持云的应用被设计为模块化、分布式、以自动化方式部署和管理。 虽然可以简单地提升和转移现有的单片应用，但这样做在成本或灵活性方面并没有任何优势。 从云计算服务所提供的分布式模型中获益的最佳方式是模块化思考——进入微服务。

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

开发人员一直在寻找提高效率和加快应用部署的方法。 API 支持软件到软件的通信并提供了开发的基础模块。 为了使用HTTP从服务器请求数据，Web 开发人员最初使用SOAP ，它以XML文档的形式发送请求的详细信息。 然而，XML 文档往往很大，需要大量开销，并且开发时间较长。

很多开发人员已经转向REST ，这是一种用于创建无状态、可靠 Web API 的架构风格和指南集。 遵循这些准则的 Web API 称为 RESTful。 RESTful Web API 通常基于 HTTP 方法通过 URL 编码的参数访问资源并使用JSON或 XML 传输数据。 通过使用 RESTful API，应用开发速度更快，并且开销更少。

技术的进步为推进应用设计带来了新的机遇。 2015 年，Google 开发了 Google 远程过程调用 ( gRPC )，作为一个可以在任何环境中运行的现代开源 RPC 框架。 REST 建立在 HTTP 1.1 协议上并使用请求响应通信模型，而 gRPC 使用HTTP/2进行传输并采用客户端响应通信模型，在协议缓冲区(protobuf) 中实现为用于描述服务和数据的接口描述语言 (IDL)。 Protobuf 用于序列化结构化数据，旨在实现简单性和性能。由于 protobuf 的效率和 HTTP/2 的使用，gRPC 在接收数据时比 REST 快大约 7 倍，发送数据时比 REST 快 10 倍。gRPC 还允许流通信并同时处理多个请求。

开发人员发现使用 gRPC 构建微服务是使用 RESTful API 的一种有吸引力的替代方案，因为它具有低延迟、支持多种语言、紧凑的数据表示和实时流式传输等特点，所有这些特性使其特别适合于微服务之间的通信以及低功耗、低带宽网络通信。gRPC 之所以越来越受欢迎，是因为它使快速高效地构建新服务变得更加容易，具有更高的可靠性和可扩展性，并且客户端和服务器都具有语言独立性。

尽管 gRPC 协议的开放特性提供了许多积极的好处，但该标准并没有提供任何保护来防止 DoS 攻击对应用的影响。 gRPC应用仍然可能遭受与传统应用相同类型的 DoS 攻击。

为什么识别 gRPC 应用上的 DoS 攻击很困难

虽然微服务和容器为开发人员提供了更多的自由和自主权，可以快速向客户发布新功能，但它们也引入了新的漏洞和利用机会。 一种越来越流行的网络攻击是拒绝服务 (DoS)攻击，近年来，这种攻击导致了越来越多的常见漏洞和暴露 (CVE)，其中许多是由于对 gRPC 请求处理不当造成的。 近年来，针对应用和 API 的第 7 层 DoS 攻击激增了 20%，影响的规模和严重程度上升了近 200%。

DoS 攻击通常会发送大量看似合法的流量，以耗尽应用程序的资源并使其无响应。 在典型的 DoS 攻击中，恶意行为者会向网站或应用注入大量流量，导致服务器不堪重负，从而导致服务器停滞甚至崩溃。 DoS 攻击的目的是减慢或完全禁用机器或网络，使需要它们的人无法访问它们。 在攻击得到缓解之前，依赖于机器或网络的服务（例如电子商务网站、电子邮件和在线帐户）将无法使用。

我们越来越多地看到使用 HTTP 和 HTTP/2 请求或 API 调用在应用层（第 7 层）进行攻击的 DoS 攻击，很大程度上是因为第 7 层攻击可以绕过并非为防御现代应用架构而设计的传统防御措施。 为什么攻击者从传统的网络层（第 3 层和第 4 层）容量攻击转向第 7 层攻击？ 他们正在走阻力最小的路径。 基础设施工程师花费了数年时间构建针对第 3 层和第 4 层攻击的有效防御机制，使得这些攻击更容易被阻止，且成功的可能性更小。 这使得发动此类攻击所需的金钱和时间成本更高，因此攻击者已转向其他攻击方式。

检测对 gRPC应用的 DoS 攻击极其困难，尤其是在自动执行扩展的现代环境中。 gRPC 服务可能不是为处理大容量流量而设计的，这使得它很容易成为攻击者的目标。gRPC 服务也容易受到h2load等工具的 HTTP/2 洪水攻击。 此外，当攻击者利用 protobuf 规范中正确声明的数据定义时，gRPC 服务很容易成为攻击目标。

gRPC 服务的一个典型（如果不是故意的）滥用是当脚本中的错误导致它对服务产生过多的请求时。 例如，假设自动化脚本在某种情况发生时发出 API 调用，设计人员希望该情况每两秒发生一次。 然而，由于条件定义错误，脚本每两毫秒发出一次调用，给后端 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 显示了遭受 DoS 洪水攻击的 gRPC应用。 在 gRPC 上下文中，关键指标是每秒数据报数 (DPS)，它对应于每秒的消息速率。 在此图中，黄色曲线表示学习过程：当基线 DPS预测收敛到传入 DPS值（蓝色）时，NGINX App Protect 已经了解了该应用的“正常”流量是什么样的。 12:25:00时DPS的大幅上升，预示着攻击的开始。 红色警报铃声表示 NGINX App Protect DoS 确信正在发生攻击，并开始缓解阶段。

图 2 显示了 NGINX App Protect DoS 在检测异常行为和使用分阶段缓解方法阻止 gRPC DoS 洪水攻击的过程中。 红色峰值表示在全局速率缓解阶段发送给所有客户端的 HTTP/2 重定向次数。 紫色图表表示当特定客户端的请求与模拟异常行为的签名匹配时发送给该客户端的重定向。 黄色图表表示发送给通过 IP 地址和 TLS 指纹识别的特定检测到的不良行为者的重定向。

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

图 4 显示了当攻击持续时，NGINX App Protect DoS 如何从基于签名的缓解转变为不良行为者缓解。 通过分析用户行为，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 天免费试用或联系我们讨论您的用例。

欲了解更多信息，请参阅我们的白皮书《保护现代应用程序免遭第 7 层 DoS 攻击》 。