现代 Web 服务领域的特点是大量细粒度、松散耦合的微服务，对低延迟的要求越来越严格。然而，这种架构也带来了新的性能漏洞。本文提出了一种新型低容量应用层 DDoS 攻击，称为同步毫秒瓶颈 (SyncM，Sync-Millibottleneck) 攻击，专门针对微服务。这种攻击的目的是造成长尾延迟问题，违反服务级别协议 (SLA)，同时逃避最先进的 DDoS 检测/防御机制。

SyncM 攻击利用了微服务架构的两个独特功能：(1) 将用户请求定向到中间层/后端微服务的共享前端网关，以及 (2) 多个逻辑上独立的执行路径共存，每个路径都有自己的瓶颈资源。通过在多个独立执行路径上创建同步的毫秒瓶颈（亚秒级持续时间），SyncM 攻击可导致每个执行路径中的排队效应在共享前端网关中传播和叠加。因此，即使所有系统资源都远未饱和，SyncM 也会在系统中触发极高延迟峰值，这使得追踪不稳定原因变得具有挑战性。

为了评估 SyncM 攻击的实用性，在配备了最先进 IDS/IPS 系统的真实云系统（如 EC2 和 Azure）上进行了广泛的实验。还使用阿里巴巴生产集群数据集进行了大规模模拟，以展示攻击的可扩展性。结果表明SyncM 攻击非常有效，仅消耗目标系统不到 15% 的额外 CPU 资源，同时将95%的响应时间提高了 20 倍以上。

0x01 简介

快速响应对于现代 Web 应用程序至关重要，尤其是对于面临巨大业务压力的电子商务。即使页面加载时间略有增加也会导致严重的销售损失。例如，亚马逊发现页面加载时间增加 100 毫秒会导致销售额减少约 1%，而谷歌 发现搜索结果延迟 500 毫秒可能会导致收入减少高达 20%。对于新兴的增强现实设备（如 Apple Vision Pro），对快速响应的需求更为关键，因为这些设备需要极其灵敏的 Web 服务来提供自然流畅的用户体验。

本文中介绍了一种称为 Sync-Millibottleneck攻击的新型小容量应用层 DDoS 攻击，该攻击专门针对微服务。SyncM 攻击的目的是引起性能不稳定，从而违反延迟敏感目标的服务水平协议 (SLA，Service-Level Agreement)，同时逃避最先进的 DDoS 检测和防御系统。SyncM 攻击会利用微服务应用的两个明显特征：

(1) 共享一个前端网关微服务，将用户请求分派到中间层/后端微服务；

(2) 多个逻辑上独立的执行路径共存，每个路径都有自己的关键资源瓶颈。

在典型的 SyncM 攻击场景中，攻击者会向目标微服务的多个选定执行路径间歇性地发送混合类型的合法 HTTP 请求。这些请求会触发这些执行路径上的同步毫秒瓶颈，从而导致排队效应，该效应会在共享前端网关微服务中传播和叠加。排队效应会产生高延迟峰值，违反电子商务的 SLA（如下图所示）。由于每个目标执行路径中产生的毫秒瓶颈仅持续数十到数百毫秒，因此所有系统资源都远未饱和（例如<50%），因此很难追踪性能下降的根本原因。

与众所周知的蛮力 DDoS 攻击相比，低容量攻击对企业构成了更大的安全威胁，因为这些攻击往往无法被发现，从而使损害持续很长时间。SyncM 攻击的新颖之处在于利用了微服务架构中新的架构级漏洞以及微服务架构中多个独立执行路径之间的同步毫秒瓶颈（例如，CPU、内存或磁盘 I/O 的毫秒饱和）。此类同步毫秒瓶颈会持续降低系统性能，同时逃避依赖粗粒度（以秒或分钟为单位）监控的最先进的 IDS/IPS 工具的检测。

实施SyncM 攻击的主要挑战是确定跨多个独立执行路径的同步毫秒瓶颈触发条件，并量化对整个系统的性能损害。为了准确理解 SyncM 攻击，使用了经过修改的排队网络来模拟攻击场景。该模型用于以数值方式分析攻击对目标系统的影响，并得出实现所需攻击目标的最佳攻击参数，因为性能损害和隐蔽性之间通常存在权衡。

为了确保 SyncM 攻击在真实云设置中有效，研究者开发了一个基于卡尔曼滤波器的反馈控制框架，以适应目标的运行时动态。该框架能够快速调整攻击参数以适应系统状态的变化。借助排队网络模型和反馈控制框架，发现了SyncM 攻击能够在各种工作负载条件和云设置下实现预定义的攻击目标，同时避免被最先进的 DDoS 检测机制检测到。

0x02 威胁模型

A. 微服务架构

在具有单片 n 层架构的传统 Web 应用程序中（见下图a），业务逻辑紧密耦合，在连续层之间产生强依赖性。由于每层都扮演着单片角色，如果某一层出现性能异常，整个系统都会受到影响。单片架构留下了一个严重的性能漏洞，允许低容量 DDoS 攻击针对系统的单个层并导致整个系统的性能显著下降。

与单片 n 层架构不同，微服务架构采用基于容器的轻量级服务，使其更能抵御现有的低容量 DDoS 攻击。上图b 显示了 SockShop 微服务基准。微服务应用程序被拆分为一组松耦合的微服务组件，每个组件都作为独立的服务运行，通过经典的 RPC 样式调用/响应与其他组件交互。一旦组件遇到性能异常，损害仅限于其本地或组件所涉及的执行路径。因此，与单片 n 层系统相比，微服务应用程序通常具有更好的性能异常容错度。特别是生产微服务（例如阿里巴巴等电子商务）应用程序可能涉及数千个组件，这些组件构成数百条具有复杂路径间依赖关系的执行路径。

B. 威胁模型

假设 SyncM 攻击者扮演普通用户的角色，通过公共 HTTP 请求访问目标微服务应用程序。攻击者事先不了解目标的内部实现以及合法用户的基线工作负载。作为普通用户，攻击者可以通过发送不同的 HTTP 请求并准确观察各个请求的端到端延迟来分析微服务应用程序。为了发起 SyncM 攻击，攻击者可以招募大量机器人同步向目标系统发送攻击请求。

C. 场景

典型的 SyncM 攻击场景如下图所示。攻击者采用 Short-ON 和 Long-OFF 脉冲方式向目标发送混合类型的合法 HTTP 请求。Short ON 周期通常为毫秒级，而 Long OFF 可以长达数秒，这既能保证危害性，又能保证隐蔽性。在 Short-ON 期间会发生以下事件序列。

事件 1：攻击者在短时间内（例如 50 毫秒）向目标系统发送大量混合类型请求。

事件 2：前端网关将每种类型的请求分派到其独立的执行路径，并在执行路径上最薄弱的组件处产生毫秒瓶颈。

事件 3：每个目标执行路径中的毫秒瓶颈都会阻止瓶颈组件处理传入请求，导致请求填满本地队列（例如线程池），并快速将排队的请求传播到其上游组件。

事件 4：来自所有目标执行路径的排队请求汇聚在其共享网关（下图b中的共享队列），导致网关中出现叠加排队效应。

事件 5：来自普通用户的请求在共享网关中遇到超长的排队延迟，导致响应时间过长（例如秒级），违反 SLA。

上述攻击场景在两种方面是隐蔽的。首先，每个 Short-ON 周期后都会有一个以秒为单位的 Long-OFF 周期，在此期间，目标系统可以冷却下来，清除系统中排队的请求，然后恢复到长时间的正常状态。其次，攻击的破坏力来自独立执行路径中多个同步的毫秒瓶颈的复合效应，其中每个毫秒瓶颈本身都是以毫秒为单位的，普通的以秒为单位采样的监控工具无法发现（例如，Amazon CloudWatch的最细粒度是 1 秒）。通过调整 Short-On/Long-OFF 周期等攻击参数以及攻击请求的选择，攻击者可以有效地平衡性能损害和隐蔽性之间的权衡。

D. 攻击测量

上表总结了 SyncM 攻击通过代表性微服务基准测试的影响，该基准测试采用部署在三个云平台中的生产设置：Amazon EC2、Microsoft Azure、NSF CloudLab。设置 EC2-SN-7k 表示云平台、基准测试系统和基线工作负载。研究者比较了目标系统在受到和不受到 SyncM 攻击的情况下的第 95 百分位和第 99 百分位响应时间，结果显示攻击导致了显著的长尾延迟问题。大多数电子商务网站和物联网后端应用程序认为这种长尾延迟问题（例如，第 95 百分位响应时间 > 3 秒）会导致严重的性能下降。同时，瓶颈微服务组件（第 9 列）的 CPU 利用率在受到攻击时仅增加不到 15%，远未达到饱和状态，这给系统管理员造成了“正常工作负荷”的假象。

0x03 攻击建模

A. 攻击模型

排队网络模型已广泛应用于复杂计算机系统的性能预测。通过使用排队网络对微服务进行建模，并分析 SyncM 攻击对性能的影响，如前图所示。在短开启期 (L) 内，攻击者发送一连串混合请求来攻击多条 (m) 执行路径。在每个Long-OFF周期 (T-L) 之后，攻击者重复该流量高峰。给定目标执行路径i，分别使用 Bi到Li表示攻击速率和长度。对于每次流量高峰，总攻击量为：

每次混合请求流量高峰都会在多条执行路径上创建同步的毫秒瓶颈，从而导致前端网关 (事件1∼5) 中出现叠加排队效应。假设目标执行路径除了网关之外没有重叠。该攻击可以分两步建模：（1）单路径攻击建模；（2）在网关中叠加排队效应的多路径攻击建模。

单路径攻击建模：尾部攻击（Tail Attack）引入了排队网络来模拟对单片 n 层系统的类似攻击。它假设网关服务器的队列大小有限，因此一旦网关队列已满，下游层中的一个毫秒瓶颈就可能降低整个系统的性能。在这种情况下，网关会启动请求丢弃，导致长时间的 TCP 重传。然而，这个假设在微服务架构上并不成立，原因有二：首先，松耦合的微服务具有更好的性能异常容错度。其次，现代微服务架构的网关通常采用异步事件驱动的调用，它可以容纳服务器内存允许的尽可能多的排队请求，因此网关不会丢弃请求。鉴于关键假设的变化，必须扩展尾部攻击中的排队模型，以与单路径攻击建模中的微服务架构保持一致。

微服务组件之间的通信通常采用 RPC 样式的调用和响应，从而产生组件间依赖关系。因此，下游组件中的一个排队请求在执行路径上的每个上游组件中都占有待处理的队列槽（例如等待响应的线程）。由于组件间依赖性，下游组件中的毫秒瓶颈可能导致跨服务队列传播到其上游组件（事件3）。为了避免队列丢失，上游组件通常配置为具有比其下游组件更大的队列大小。然后，对于目标执行路径上的所有微服务，填满每个队列所需的时间为：

其中，队列填充时间li是使用第i个组件的可用队列槽除以第i个组件的队列的队列填充率得出的。一旦下游组件中的所有队列都填满，网关将在剩余的攻击“ON”期间（lgatew