在过去两年里，客户对产品和服务的需求变得越来越重要。在此大背景下，企业轻松扩展和加速创新的能力变得至关重要，这也促使很多企业加速了应用从单体架构往云原生架构迁移的进程。根据 F5 发布的《2021 年应用策略现状报告》，仅去年一年，对应用进行现代化改造的企业数量就增加了 133%。云原生应用在设计上呈模块化和分布式，以自动化方式进行部署和管理。尽管可以直接把现有的单体应用简单的迁移到云平台，但这种做法在成本和灵活性上不占优势。想要从云计算服务的分布式模型中充分获益，最佳方法还是采用模块化的微服务架构。
微服务架构支持开发人员将应用构建为一组轻量化的应用服务，这些应用在结构上彼此独立，并且不受底层平台的限制。每个微服务都作为独立的进程运行，通过定义完善的标准化 APIs 与其他服务进行交互。每个服务均可由小型独立团队开发和部署。得益于这种敏捷性，企业可在性能、成本、可扩展性及加速创新的能力上获得大幅度提升。
开发人员一直想方设法提高效率并加快应用部署。API 支持软件之间通信，并提供用于开发的构建块。在使用 HTTP 向服务器请求数据时，Web 开发人员原先借助于 SOAP，需要通过 XML 文档来传递请求详情。但是，XML 文档往往很大，需要大量开销，并且开发周期较长。
因此，许多开发人员逐渐开始使用 REST，这种架构风格为创建可靠的无状态 Web API 提供了一套准则。遵守这些准则的 Web API 被称作 RESTful。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 倍左右，发送数据的速度快了 10 倍。gRPC 还支持串流通信，并且能够同时响应多项请求。
开发人员发现，gRPC 具有低延迟、支持多种语言、数据表达紧凑、支持实时串流的特点，特别适合在低功耗、低带宽的网络环境中在微服务间通信，因此能够有效替代 RESTful API 进行微服务架构的构建。得益于支持快速高效地构建新服务、更出色的可靠性和可扩展性以及面向客户端和服务器端的语言独立性，gRPC 已经变得越来越受欢迎。
尽管 gRPC 协议的开放性可带来不少好处，但无法保护应用免遭可能的 DoS 攻击。gRPC 应用仍有可能遭到与传统应用相同类型的 DoS 攻击。
为什么难以识别针对 gRPC 应用的 DoS 攻击
尽管微服务和容器为开发人员提供了更多的自由和自主权，可以快速向客户发布新功能，但同时也不可避免的引入了新的漏洞。在众多网络攻击中，拒绝服务 (DoS) 攻击日益猖獗，近几年来造成的通用漏洞披露 (CVE) 与日俱增，其中许多是由于对 gPRC 请求的处理不当造成的。最近几年，针对应用和 API 的七层 DoS 攻击激增 20%，同时其影响规模和严重程度增加了几乎 200%。
DoS 攻击通常会发送大量流量，这些流量看似合法，但会慢慢耗尽应用的资源，最终导致应用无法响应。在典型的 DoS 攻击中，攻击者会使用大量流量淹没网站或应用，使得无法承受海量请求的服务器最终瘫痪或甚至崩溃。DoS 攻击旨在使服务器或网络减缓或彻底瘫痪，使正常的业务流量无法按需访问。在攻击得到缓解之前，那些依赖于受影响设备或网络的服务，例如网上商城、电子邮件和在线帐户服务，将无法使用。
我们已观察到越来越多的 DoS 攻击开始使用 HTTP 和 HTTP/2 请求或 API 调用，针对应用层（七层）发起攻击，这在很大程度上是因为七层攻击可以绕过那些无法为现代应用架构提供有效保护的传统防御机制。为什么攻击者从针对网络层的传统流量耗尽攻击（三层和四层）转向七层攻击？因为他们遵循最小阻力原则。基础架构工程师们已经花费了多年的时间来构建针对三层和四层攻击的有效防御机制，因此三层和四层攻击更容易被拦截下来，成功率更低。想要实现成功的三层或四层的攻击，攻击者们需要在上花费更多的成本和时间，因此攻击者们不得不转移攻击目标。
针对 gRPC 应用的 DoS 攻击很难被探测，尤其是在可自动扩展的现代应用环境中。被设计成无法处理大规模流量的 gRPC 服务很容易成为攻击者的目标。gRPC 服务也极易遭到使用 h2load 等工具发起的 HTTP/2 泛洪攻击。此外，借助 Protobuf 规范中的明确数据定义，攻击者可轻松针对 gRPC 服务发起攻击。
典型的（如果是无意的）gRPC 服务滥用是指脚本因漏洞向 gPRC 服务发起过多请求。例如，假设自动化脚本会在特定条件下发起 API 调用，设计师期望每两秒钟发起一次。但是，由于条件设置错误，脚本每两毫秒就发起一次调用，这就会给后端 gRPC 服务造成巨大负担。
除此之外，针对 gRPC 应用的 DoS 攻击还包括：
- 在 gRPC 消息中插入恶意字段，以导致应用故障。
- Slow HTTP
POST攻击，在 gRPC 请求头中发送不完整的请求。为等待请求的其余部分，应用或服务器始终保持连接状态，占用连接数。当并发连接池变满后，就会拒绝正常客户的其他连接请求。 - 在 HTTP/2 Settings Flood (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 旨在防御最“老谋深算”的七层 DoS 攻击，使用独特的算法来创建动态统计模型，用以实现自适应机器学习和自动化保护。它能不断地衡量防御效率，适应不断变化的用户和站点行为，并执行主动式的服务器健康检查。更多详情，请查看我们的博文《NGINX App Protect Denial of Service 如何适应不断演变的攻击形势》。
NGINX App Protect DoS 针对传统的 HTTP 应用和现代 HTTP/2 应用请求头进行行为分析，同时基于特征库和攻击者标识来抵御攻击。在初始的特征库防御阶段，NGINX App Protect DoS 会对与异常行为相关的特征进行分析，并创建动态特征库，以拦截未来与此行为相匹配的请求。如果攻击持续存在，NGINX App Protect DoS 就会转入攻击者防御阶段。
基于异常统计的监测结果，NGINX App Protect DoS 可通过源 IP 地址和 TLS 指纹来锁定攻击者，并基于此生成并部署动态特征库，以自动识别和抵御这些特定的攻击流量。与市场上的那些简单监测流量何时超过阈值的传统 DoS 解决方案不同，在一些攻击中，请求看似完全合法，每位攻击者所产生的流量甚至少于普通合法用户，对于这一类攻击，NGINX App Protect DoS 也能够准确识别并拦截。
以下 Kibana 仪表盘展示了 NGINX App Protect DoS 如何快速自动地监测和抵御针对 gPRC 应用的 DoS 泛洪攻击。
图 1 显示了正在遭受 DoS 泛洪攻击的 gRPC 应用。在 gRPC 的相关指标中，与消息交互速率相对应的每秒数据报数 (DPS) 是一项关键指标。在此图中，黄色曲线代表学习过程：当基准 DPS（黄色）预测朝请求 DPS （蓝色）聚合时，表示 NGINX App Protect 已经学会了该应用“正常”的流量模型。DPS 在 12:25:00 的急剧上升表示攻击开始。红色警铃表示此时 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 指纹锁定攻击者。服务将直接拒绝来自特定攻击者的攻击，而不再查看每项请求是否命中特征库。这样的工作机制使得 NGINX App Protect DoS 可以生成动态特征库，实现自动识别并防御这些特定攻击的模式。
借助 gRPC API，您可以使用 gRPC 接口在类型库问价 (IDL) 以及 Protobuf 的定义文件中设置安全策略。这是一个零接触的安全策略部署解决方案，您无需依靠 Protobuf 定义来保护 gRPC 服务免遭攻击。gRPC 的 proto 文件可以自然地作为 CI/CD 流水线的一部分，通过自动化保护和支持全面 CI/CD 流水线集成的安全即代码，使安全和开发团队保持一致。NGINX APP Protect DoS 可通过将安全防护无缝集成到 gRPC 应用中确保一致的安全性，使这些应用始终受到最新安全策略的保护。
虽然 gRPC 提供了开发人员设计和部署现代应用所需的速度和敏捷性，但其框架固有的开放性使其极易遭受 DoS 攻击。要想有效防御严重的七层 DoS 攻击，以避免性能下降、应用和网站中断、收入损失以及客户忠诚度和品牌声誉受损，您需要一款现代防御解决方案。NGINX App Protect DoS 能够为现代 gRPC 应用提供有力保护。
如欲试用 NGINX Plus 的 NGINX App Protect DoS，请立即下载 30 天免费试用版，或联系我们讨论您的用例。
