摘要：最近的加密勒索软件通过结合高度并行的加密和快速的文件替换，在几分钟内就能放大损害。由于即使使用精确的检测器也无法将检测延迟降至零，因此有效的防御需要在进行加密之前就采取措施来减轻损害，以确保数据的可恢复性。本文扩展了实时打开文件备份系统（ROFBS），该系统在文件打开事件发生时创建备份，并解决了在高吞吐量或突发加密情况下ROFBS失败的问题。这种失败被建模为“基本时间尺度不匹配”，即备份完成时间超过了明文变得不可逆地不可用的有效时间窗口。为了在不完全依赖更快备份的情况下恢复时间余量，本文提出了时间尺度重配置（TSR），它通过干预加密执行时间和计算资源分配来实现这一目标。TSR通过扩展的伯克利数据包过滤器（eBPF）来实现，用于观察受保护文件的打开事件并应用模块化的延迟控制。评估的控制措施包括进程挂起、通过cgroup v2进行CPU份额限制、通过sched_ext（SCX与scx_flatcg）进行调度器层控制，以及通过cpuset进行CPU并行性限制。在多个Linux勒索软件样本（Sodinokibi、IceFire、HelloKitty、AvosLocker、Conti、Monti、REvil和LockBit）上的实验中，使用CovB、EwB和PreB以及计数NE、NS、NB和NEB来量化备份完成情况、加密目标覆盖率和备份精度。结果表明，挂起的有效性受应用窗口设计的影响，在相同的权重下，调度器层的选择可以显著改变结果，而并行性限制仅对特定家族的勒索软件有益。总体而言，当能够早期干预并且主要瓶颈与选定的控制手段相匹配时，TSR最为有效。CCBY - IEEE不是该材料的版权所有者。请通过https://creativecommons.org/licenses/by/4.0/获取全文文章和API文档中的规定。
第一节 引言
勒索软件大致可以分为两类：加密勒索软件，它加密受害者的文件和数据以索取赎金；以及锁定勒索软件，它锁定受害者的计算机并阻止正常操作[1]。近年来，加密勒索软件已成为主要威胁，其事件数量持续增加。根据CyberEdge的报告，2023年有72.7%的组织受到了勒索软件攻击的影响，这是自2018年以来的最高比例[2]。此外，攻击变得越来越复杂和多样化，Allianz预测到2031年全球年度损失可能达到约2650亿美元[3]。
现有的针对勒索软件的对策大致可以分为检测和损害缓解（防御）两类，最近的研究特别强调了提高检测精度。传统的基于签名的方法使用文件名和哈希等静态特征来识别恶意软件，但它们对变种和以前未见过的样本效果较弱[4]。受此限制的启发，许多研究调查了使用机器学习的基于行为的检测方法。例如，Amjad和Abdulmohsen展示了机器学习模型可以学习勒索软件的行为模式并检测异常[5]，Beaman等人报告说，基于进程行为的分类器在有足够的训练数据的情况下可以实现高检测性能[6]。然而，正如Kok等人指出的，与检测相比，关于防御（损害缓解）模型的研究仍然相对有限[7]。即使使用高度精确的检测器，也无法将检测延迟降至零，这留下了一个时间窗口，在此期间加密可以继续进行并造成不可逆的损害。现代勒索软件通过使用高度并行的加密（多线程）和快速的文件替换，加剧了这一挑战，使得端点用户数据的快速破坏成为可能。因此，仅依赖计划好的备份或事件后的恢复往往不足以保持数据的最新状态。因此，不仅仅是检测到加密活动后开始备份，还需要控制加密进程的时间尺度，并延迟加密直到备份完成。
在我们之前的工作中，我们提出了实时打开文件备份系统（ROFBS），这是一种利用文件打开事件作为触发器实时创建备份的防御模型，并证明了在某些条件下它可以显著减轻加密损害[8]。然而，当勒索软件进行高吞吐量或突发加密时，ROFBS可能无法跟上，导致可恢复性下降。为了正式描述这种竞争，让Etime表示直到明文不可逆丢失的有效每文件时间窗口，让Btime表示完成有效备份所需的每文件时间（包括事件处理和元数据操作等开销）。只有当Btime≤Etime(1)时，实时备份才能跟随加密[1]。
相反，持续违规（Btime>Etime）代表了由攻击（加密进度）和防御（备份完成）的时间尺度不匹配引起的根本性冲突，而不是实现错误。在本文中，我们将这种情况称为“基本时间尺度不匹配”。
本研究基于ROFBS，并研究了一个不依赖于加速备份的框架。具体来说，我们干预加密的执行时间和计算资源的分配，以人为地延长有效时间窗口Etime，并延迟加密进度直到备份完成。我们称这种方法为时间尺度重配置（TSR）。TSR的目标是通过控制加密进度的速度来创造时间余量，从而即使在基本时间尺度不匹配的情况下也能稳定损害缓解。我们将将基于TSR的延迟控制集成到ROFBS中的扩展方案称为ROFBS-TSR。ROFBS-TSR在观察到文件打开事件时干预加密进度的时间尺度，旨在通过延迟加密直到备份完成来恢复备份的同步能力。此外，我们采用了一种将检测过程与备份过程分离的架构，以在比较延迟控制机制时最小化实现依赖性。
在ROFBS TSR中，我们使用扩展的伯克利数据包过滤器（eBPF）以低开销检测文件打开事件，并将延迟控制实现为一个可替换模块，应用于对受保护文件的访问。从干预执行时间和干预计算资源分配的两个角度，我们应用并比较了以下控制机制。这些机制包括使用SIGSTOP和SIGCONT进行基于暂停的延迟、使用cgroup v2（cpu.weight）进行CPU份额控制、使用sched_ext（SCX与scx_flatcg）结合cgroup weight控制进行调度器层控制，以及使用cpuset进行CPU并行性限制。这种设计使我们能够分别评估是否可以创建备份以及备份是否能够跟上加密目标的步伐。它还允许我们澄清勒索软件之间的行为差异（如高度并行的加密、文件替换和注解生成）如何影响基于延迟的防御的有效性。
实验从四个角度组织。首先，我们比较了基于挂起的控制的固定持续时间和备份完成应用窗口，并评估窗口设计如何影响同步能力。其次，我们在固定的cpu.weight下比较了传统调度器（CFS）和可扩展调度器（SCX），以隔离调度器层对加密延迟和跟踪的影响。第三，我们比较了固定持续时间和备份完成应用窗口，以评估针对高度并行加密的有效条件和限制。第四，我们使用GPG和文件复制到LUKS挂载的加密卷来评估延迟控制对良性工作负载的影响，以评估实际部署能力。此外，我们对代表性样本进行了初步的敏感性分析，以检查对固定参数设置的依赖性。我们使用多个Linux勒索软件样本（Sodinokibi、IceFire、HelloKitty、AvosLocker、Conti、Monti、REvil和LockBit）来评估这些设置。
为了便于解释结果，我们采用了区分可行性、覆盖率和精度的指标。具体来说，我们引入CovB来表示备份创建的可行性，EwB来表示备份对加密目标的覆盖率，PreB来表示生成的备份相对于加密目标的精度。通过分析这些比率以及相应的绝对计数NE、NS、NB和NEB，我们可以定量区分备份被创建但未能跟上加密目标的情况。
请注意，本研究没有提出硬件辅助的保护机制。其范围仅限于使用Linux上可用技术的操作系统级软件设计，包括通过eBPF观察文件打开、通过cgroup进行进程挂起、通过sched_ext进行调度器层控制以及通过cpuset进行CPU并行性限制。
本文的主要贡献总结如下。我们系统化了一个基于TSR的损害缓解框架，该框架从文件打开观察开始操纵加密进度的时间尺度，并通过多种控制机制实现它，包括进程挂起、在CFS和SCX下的cgroup重量控制以及CPU并行性限制。我们提出了一种评估方法，使用CovB和EwB区分可行性和覆盖率，并进一步使用PreB量化备份精度，即使在恶劣条件下也能进行瓶颈分析和方法比较。通过使用多个勒索软件样本，我们实验性地描述了应用窗口、调度器层和CPU并行性限制如何影响跟踪和整体效果。我们还通过初步的敏感性分析和良性工作负载评估来补充核心评估，从而明确了参数依赖性和实际部署能力。
第一节回顾了与勒索软件检测和损害缓解相关的工作。第三节总结了本研究中使用的内核级观察技术（eBPF），定义了基本时间尺度不匹配为加密和备份之间的时间尺度不匹配，并说明了它在ROFBS行为中的表现。第四节描述了时间尺度重配置（TSR）以及ROFBS TSR的设计和实现，该方案通过干预加密执行时间和计算资源分配来增加时间余量。第五节描述了实验设置、工作负载和指标。第六节报告了结果。第七节讨论了发现和局限性。第八节总结了本文并概述了未来的工作。
第二节 相关工作
本节回顾了从硬件和软件两个方面对勒索软件防御的先前研究。前者在子节II-1中讨论，后者在子节II-2中讨论。这些研究的调查是为了将当前工作置于勒索软件对策研究的更广泛背景中。请注意，所提出的ROFBS TSR是一个操作系统级软件设计，不需要专用硬件、SSD内部逻辑或设备级修改。
1) 硬件和设备辅助方法：一些研究通过将保护逻辑卸载到存储设备或利用设备级机制来探索勒索软件防御。Gujar等人提出了一个实时检测新添加文件并立即将其备份到SSD内专用文件夹的软件。由于保护软件位于SSD上，并且与主机机器分离，因此该方法可以提供比在可能被破坏的主机上运行的软件更强的数据保护。同时，作者指出了针对特定SSD模型的优化和实时处理开销等挑战[9]。
Reidys等人提出了一个勒索软件感知的SSD（RSSD），它在SSD内部实现硬件辅助日志记录，以应对针对SSD行为的新兴攻击，如强制垃圾收集、故意减慢加密速度和滥用TRIM命令[10]。他们的评估表明，RSSD可以在几乎没有性能开销的情况下防御新的和未来的勒索软件攻击。
Baek等人提出了SSD-Insider++，这是一种存储级防御系统，旨在防止勒索软件攻击下的文件损坏。通过将保护与主机机器分离，该系统旨在比容易受到规避的基于软件的方法更加稳健。他们报告说，SSD-Insider++在大多数情况下都能高精度地检测到勒索软件，并能够实现即时恢复，数据损失率为0%[11]。
Mir等人提出了缓存辅助的勒索软件检测和恢复（CARDR），它利用SSD DRAM缓存来在SSD级别对抗勒索软件[12]。在他们的评估中，CARDR的检测速度比SSD-Insider++快（大约11秒对比14秒），并将恢复队列大小减少了约42%。
Fujinoki和Manukonda提出了PDPZR，这是一种备份机制，它在每次数据更新时创建即时备份并删除过时的备份。他们的模拟结果表明，PDPZR是减轻零日勒索软件造成的损害的有希望的解决方案，同时强调了需要更多样化的实验和自动保护策略的仔细配置和调整[13]。
Zhu等人提出了LAST，这是一种针对基于闪存的SSD的入侵检测感知版本控制系统[14]。据报道，LAST与传统SSD相比仅增加了1.5%的延迟开销，同时保留了长达126.4天的数据历史（平均52.6天）。作者还报告称，这种保留期至少比现有的版本控制方法长61.4%，最多可长达165.9%。朱等人还提出了一种名为SrFTL的机制，该机制监控SSD/FTL层的I/O活动，将操作系统级别的文件信息传输到TEE以确定行为是否类似勒索软件，并在检测到此类行为时，通过暂停垃圾收集及相关进程来延迟受影响数据的删除[15]。根据他们的实验，SrFTL实现了零误报率，并且能够在平均9.3秒的时间内快速恢复数据，针对评估的勒索软件样本有效。Min等人提出了AMOEBA，这是一种设备级别的备份解决方案，不需要额外的存储空间来存储备份数据[16]。他们使用Microsoft SSD模拟器实现了AMOEBA，并在OpenSSD平台上对其进行了原型测试。他们的评估表明，在实现高勒索软件检测准确性的同时，性能开销可以忽略不计。Friday和Bou-Harb提出了一种方法，将基于长短期记忆（LSTM）的分类过程完全转移到计算存储驱动器（CSDs）上[17]。他们认为，这种方法可以在数据量迅速增加的情况下减少数据中心的CPU负载，并且通过直接将勒索软件防御任务卸载到CSDs上，可以有效防止数据被加密。
2) 基于软件的方法：
Hernández等人开发了R-Locker，这是一种防御系统，它利用诱饵文件来通过监控文件访问行为来防止勒索软件造成的文件损坏[18]。通过放置诱饵文件并观察其访问模式，该系统可以在关键用户文件被加密之前阻止恶意活动。
Medhat等人提出了一种混合方法，通过扫描进程内存转储和掉落的可执行文件来检测打包的勒索软件样本。通过加强YARA规则框架并描述常见的勒索软件特征，他们的方法据称能够检测到大约98%的转储文件。
Zhuravchak等人提出了一种基于蜜罐的方法来减轻文件系统的损坏。他们的方法监控对蜜罐文件的访问，并据此识别出负责的勒索软件进程[19]。
Lee等人关注勒索软件二进制文件中硬编码的文件扩展名，并提出了一种保护方法，该方法随机化重要文件的扩展名。他们报告称，这种方法成功阻止了143个勒索软件样本中的141个被加密[20]。
这些方法的一个共同局限性是，它们依赖于一些假设，例如诱饵文件会被早期访问，或者对手使用特定的扩展名选择策略（例如白名单）。因此，对于那些以随机顺序加密文件或使用黑名单进行选择的勒索软件，这些方法可能无效。
最近的研究还强调了预加密检测和主动保护机制。Kok等人提出了一种基于机器学习的预加密检测算法，用于在加密开始之前检测加密勒索软件。他们的评估显示，该算法的误报率为1.56%，AUC为99.3%，表明它是一种强大的工具，可用于检测和阻止多种加密勒索软件攻击[21]。
Song等人提出了一种针对Android系统的机制，该机制利用处理器利用率、内存使用率和I/O率来检测异常行为。在检测到异常后，系统会暂停勒索软件进程，提示用户确认，然后删除该程序以保护用户数据，而无需维护显式的勒索软件签名[22]。
Cusack等人提出了一种基于流处理的方法，该方法使用可编程转发引擎（PFE）并利用随机森林分类器来识别恶意网络活动。他们的实验表明，基于流的指纹识别技术可以实现对加密勒索软件的充分检测[23]。
除了检测之外，还有一些研究关注以备份为中心的缓解措施。Oujezsky等人提出了智能恶意软件防御系统（IMDS），该系统使用AI和哈希函数来降低备份数据中的感染风险。IMDS在备份之前验证数据完整性，并在检测到异常时阻止备份，认为这种设计比传统的被动备份方案提供了更强的保护[24]。
Ahmed等人提出了一个名为Peeler的机制，该机制通过监控文件和进程的系统级活动来检测勒索软件[25]。他们在包含67个勒索软件家族的大型数据集上评估了Peeler，并报告了99.5%的F1分数。
Ganfure等人提出了一个系统框架，该框架使用机器学习生成欺骗性文件，并通过与这些欺骗性文件的交互来检测/阻止勒索软件[26]。他们报告称，RTrap可以在每10,311个合法用户文件中平均只丢失18个文件的情况下检测到勒索软件[26]。
Anand等人提出了Linux反勒索软件监控器（LARM），这是一种为x86_64架构上的Linux系统量身定制的轻量级实时检测工具[27]。LARM结合了基于eBPF的实时监控、非参数聚类以及对加密顺序行为的启发式分析，动态选择用于监控的诱饵文件。他们的评估显示，LARM的平均检测延迟为1,240毫秒，文件丢失率为0.46%，证明了其在Linux上的早期检测和缓解效果。
Wang等人提出了Cancal系统，该系统在监控层选择性地过滤可疑进程并通过深入分析来检测勒索软件[28]。基于五个月的评估，他们报告了99.65%的真正阳性率，接近零的误报率，30毫秒内的推理时间，以及最多3秒内的实时响应。
von der Assen等人提出了GuardFS，这是一种基于文件系统的方法，用于研究勒索软件检测和缓解的集成[29]。他们在反应式环境中的评估表明，虽然无法完全防止数据泄露，但可以显著减少数据泄露。
第三节 背景和问题设定
A. 扩展的伯克利数据包过滤器（eBPF）
eBPF是一种在Linux内核中执行受限字节码程序的机制，允许动态地将观察和控制逻辑附加到各种内核钩点[30]。使用eBPF，可以在不修改内核源代码或构建和加载内核模块的情况下，为内核事件引入自定义处理。在加载时，eBPF验证器会检查程序的安全属性（例如，防止无效的内存访问和强制终止），从而降低了由于错误扩展而导致系统不稳定的风险。因此，eBPF已被广泛用于应用程序跟踪、性能分析、网络可观测性和安全监控。
历史上，eBPF程序可能依赖于内部内核数据结构（例如，结构布局），这可能导致跨内核版本的移植性问题。最近的机制，如“编译一次，到处运行”（CO-RE）和BPF类型格式（BTF），通过提高跨内核版本的移植性来解决这个问题。
BPF编译器集合（BCC）是IOVisor项目提供的eBPF开发和操作框架，提供用于跟踪和监控的库和工具集[31]。在BCC中，内核中的eBPF程序用C语言编写，通过LLVM/clang编译成eBPF字节码，然后加载到内核中，并附加到选定的钩点。用于程序协调以及处理和存储收集数据的用户空间逻辑可以用Python或Lua编写，从而在内核执行和用户空间数据处理之间实现清晰的分离。此外，BCC附带了实用的、面向任务的工具，使其适合快速仪器化和测量。
B. 基本时间尺度不匹配
本文将传统ROFBS在某些条件下无法跟上备份创建速度的现象解释为加密（攻击）和备份（防御）时间尺度之间的不匹配。当这种不匹配持续存在时，备份延迟会自我放大，积压会随着时间的推移而增长。我们将这种情况称为基本时间尺度不匹配。图1显示了一个典型的案例，其中备份无法跟上加密的速度。
为了将抽象的时间窗口Etime和Btime与我们实验中观察到的量联系起来，我们进一步将它们分解如下。设Te表示每个文件的加密时间，Δe表示加密间隔，Ld表示从检测到打开到开始备份的初始延迟，Tb表示每个文件的备份处理时间。为了使ROFBS能够跟踪加密流，备份侧在每次加密事件上花费的时间Ld+Tb不能超过攻击者侧的时间预算Te+Δe。跟踪失败的主要原因可以总结如下：
Tb+Ld>Te+Δe。(2)
为了简化讨论，我们引入了时间松弛S作为加密和备份之间的时间差：
S:=(Te+Δe)−(Ld+Tb).(3)
当S>0时，每次加密事件都有足够的松弛时间，备份过程可以跟上加密事件流。相反，当S≤0时，等式(2)成立，不完整的备份会累积，积压会增加。在本文中，我们将S≤0的情况以及时间尺度不匹配占主导地位的情况称为基本时间尺度不匹配。
C. 在基本时间尺度不匹配下的ROFBS：一个示例
实时打开文件备份系统（ROFBS）是一种使用文件打开事件作为触发器来实时创建备份的防御模型[8]。其主要目标是在加密或替换发生之前为目标文件创建备份副本，从而提高可恢复性。图2展示了传统ROFBS在连续加密下的行为。图中，红色十字表示原始文件在加密过程中被删除，而绿色备份文件表示备份创建成功。如图2a所示，传统ROFBS按文件顺序进行备份。然而，由于勒索软件加密通常具有高连续性和短的事件间隔，即使第一个备份按时完成，后续文件也可能在相应的备份完成之前被加密和删除，如图2b所示。在操作上，失败表现为加密或删除抢先于备份启动，或者在备份仍在写入时原始文件被删除的情况。
根据方程(3)中定义的时间松弛S，对于第一个目标文件，如果S是非负的，备份可能会成功；而对于后续文件，当S变为负值时，跟踪可能会崩溃。在图1中，加密或删除可能在备份启动之前发生，原始文件可能在备份过程中被删除。在S≤0的情况下，不完整的备份会系统性地增加，对于k≥2的目标文件，会导致备份丢失。
重要的是，这种行为不仅限于加密间隔Δe始终较小的工作负载。在混合小文件和非常大文件的工作负载中，Tb的短暂峰值可能会导致S变为负值，从而影响后续文件。换句话说，即使平均Δe适中，单个高峰负载事件（较大的Tb）也可能触发一系列失败，严重降低跟踪能力。
虽然ROFBS在有利条件下可以通过顺序备份来减轻损害，但它缺乏一种机制来干预加密进度的时间尺度，以在S变为负值时将其恢复为正值。因此，一旦ROFBS进入这种状态，除非加密吞吐量减少，否则恢复跟踪性能变得困难。
第四节 时间尺度重新配置
A. 时间尺度重新配置的定义
在前一节中，我们展示了当由于加密和备份之间的时间尺度不匹配导致时间松弛S变为负值（方程(3)）时，不完整的备份会累积，跟踪能力会系统性地下降。这种以不匹配为主的情况被称为基本时间尺度不匹配。传统ROFBS的一个关键限制是它无法直接干预加密进度的时间尺度。一旦系统进入S≤0的状态，就没有机制可以将S恢复为正值，这就是本文要解决的差距。
为了弥合这一差距，本研究采用了一种设计原则，即有意延迟加密进度，以便恢复备份能够“及时完成”的条件。具体来说，在文件访问（打开）时，防御机制人为地延长了有效的加密时间和/或加密间隔，从而恢复时间松弛S。这种框架被称为时间尺度重新配置（TSR）。
TSR的目标不仅仅是通过加速备份处理来竞争，而是通过操纵加密进度的时间尺度本身，使系统从S≤0的状态转变为满足S≥0的状态。
B. 两种时间尺度重新配置的方法
TSR可以概念性地分为两种干预加密进度的方法。
第一种方法干预执行时间。它暂时抑制加密过程的执行，并在加密事件序列中明确插入等待时间。进程暂停和恢复（例如，暂时停止然后继续执行）是典型的例子。图3a展示了由受保护文件的首次打开事件触发的加密进度延迟。图3b表明，通过引入这种延迟，备份处理更有可能在加密之前完成，从而增加了后续文件的备份在加密和删除之前完成的可能性。图3提供了ROFBS-TSR的概述，其中故意延迟加密进度以创建实时备份的时间缓冲。图3. ROFBS-TSR概述：延迟加密进度以创建实时备份的时间缓冲。
第二种方法干预计算资源。它限制分配给加密过程的CPU时间和/或并行度，降低加密吞吐量，并有效地延长加密时间和/或加密间隔。在本文中，通过cgroup v2使用cpu.weight进行CPU份额控制，通过sched_ext (SCX)使用scx_flatcg结合cgroup weight控制进行调度器层控制，以及通过cpuset进行CPU并行度限制，被视为这种方法的具体实例。在本文的其余部分，这些干预措施统称为延迟控制。延迟控制激活的时期被称为延迟窗口。对于基于暂停的控制，延迟窗口表现为一个明确的暂停间隔；而对于CPU份额控制或并行度限制，加密会继续进行，但速度减慢。图4概念性地展示了延迟窗口如何扩展加密间隔并为备份处理提供额外的时间裕度。
为了概括延迟控制如何改变跟踪条件，分析用时间缓冲S来表达。假设延迟控制将加密事件的总时间预算增加了τ>0，并且应用和释放控制引入了一个常数开销δ≥0。那么，跟踪条件可以重写为：
Tb+Ld+δ≤Te+Δe+τ。(4)
使用方程(3)中的缓冲定义，应用TSR后的新缓冲表示为Stsr，计算如下：
Stsr:=(Te+Δe+τ)−(Ld+Tb+δ)=((Te+Δe)−(Ld+Tb))S+τ−δ=S+τ−δ。(5)
等价于方程(4)，当Stsr≥0时，顺序跟踪成立，意味着备份可以“及时”完成与加密相关的任务。
重要的是，即使原始缓冲S为负值，如果延迟控制提供的额外时间τ−δ足够大，也可以恢复跟踪能力，即Stsr=S+τ−δ>0。
因此，即使在基本时间尺度不匹配的情况下（S≤0占主导），TSR也可以通过重新配置时间尺度来恢复保持同步的能力。
C. 应用窗口
延迟控制的效果和副作用取决于其激活的时间以及维持的时间长度。本文定义了两种类型的应用窗口，并通过实验进行了比较。在固定持续时间窗口中，延迟控制在首次打开事件（或检测器警报）时激活，并在预定持续时间W后释放。这种设计直接明了，并为控制持续时间提供了明确的上限。然而，它可能在备份完成之前释放控制，或者相反，在备份完成后仍然维持不必要的延迟。在备份完成窗口中，延迟控制在打开事件时激活，并持续到系统被认为已恢复到可跟踪状态。具体来说，释放条件与相关备份处理的完成和备份积压的清除相关联。这种设计可以以适应工作负载的方式确保跟踪恢复所需的时间。同时，它需要状态管理来决定何时释放控制，而且根据情况，控制持续时间可能会变长。
这些窗口定义与上述两种干预方法（执行时间和计算资源）是正交的，并且可以独立组合。在以下实验中，评估了延迟机制和应用窗口的选择对CovB和EwB的影响。
A. 设置和工作负载
表1总结了本研究中使用的基于软件的评估环境。实验是在运行在Windows 11主机上的AlmaLinux 10.1客户虚拟机上进行的。受保护的目录放置在XFS上，文件打开事件通过xfs_file_open进行观察。这些规格是为了便于重现性而报告的，并不意味着所提出的方法需要硬件辅助或基于虚拟机的部署。
表1 实验环境（主机和客户虚拟机）。
为了评估延迟控制对ROFBS跟踪能力的影响，使用八个勒索软件样本进行了实验：Sodinokibi、IceFire、HelloKitty、AvosLocker、Conti、Monti、REvil和LockBit。在本文中，样本标签遵循样本收集和签名识别时分配的名称。这些样本是在2023年5月至10月和2026年3月期间从互联网上收集的。表2列出了实验中使用的样本的MD5哈希值。
对于所有实验条件，进行了五次独立运行，结果表中报告的值对应于五次运行的平均值和标准差。因此，尽管NE、NS、NB和NEB是基于唯一基名的计数量，但在修订后的手稿中它们被报告为五次运行的平均值。
受保护的目录是一组位于/home/user/victim/下的用户文件。只有当观察到对/home/user/victim/下的路径的访问时，才会触发备份处理。
与之前的ROFBS实现不同，本研究不在单个进程中执行检测和ROFBS备份创建。相反，检测过程和备份过程被分离并作为不同的进程执行[32]。这种设计旨在减少模型推断和备份生成之间的干扰，并在比较不同的延迟控制机制时最小化实现依赖性。在以下实验中，这种分离的架构在所有条件下都是一致的，包括基线情况，只有表3中列出的控制方法会发生变化。
触发器是使用eBPF进行的文件打开检测。从打开事件中重建文件路径，并与受保护目录进行匹配以确定备份目标。对于所有控制方法，都会识别发出打开操作的执行实体的PID和PPID，并对两者应用延迟控制。
在打开触发的备份方案中，辅助文件（如勒索提示）可能会比用户数据更早被观察到。在这种情况下，备份处理可能会被吸引到这些辅助文件上，从而延迟用户数据的备份。尽管勒索提示通常恢复的优先级较低，但它们可以在加密开始之前创建和放置，这可能会加剧积压的增长。例如，据报道AvosLocker在开始加密之前会在每个目录中放置勒索提示[33]。此外，先前的研究报道勒索提示的文件名和内容经常包含“decrypt”和“file”等术语，而类似于“ReadMe”或包含解密指令关键字的文件名也经常被使用[34]。
作为一种实际的缓解措施，本研究在选择阶段过滤备份目标。具体来说，如果文件名与[34]中报告的勒索提示命名模式匹配，则该文件将被排除在备份之外，并立即终止该打开事件的备份程序。这种策略抑制了由于优先备份勒索提示而导致的积压膨胀，并优先考虑用户数据的跟踪。
在本研究中，与文件打开观察相关的额外延迟被视为Ld的一部分。然而，Ld不仅指eBPF钩子本身的延迟；而是解释为一个非零的延迟组件，它取决于实现和执行环境，包括钩子执行、事件收集和用户空间调度。Jia等人报告说，传统的系统调用过滤可能会由于用户空间代理而产生上下文切换开销，而基于eBPF的过滤可以减少这种开销[35]。Vieira等人还将eBPF/XDP描述为高性能内核包处理的基础，支持eBPF被广泛用作低开销内核处理底层的观点[36]。因此，本文不假设eBPF引入的观察延迟为零；相反，Ld被视为一个可能随实现和执行环境变化的实际延迟项。
B. 实验因素
比较的条件包括没有延迟控制的基线（ROFBS）和具有延迟控制的多个变体。在主要的勒索软件实验中，数据集、受保护的路径、打开检测方法和备份生成逻辑是固定的。只有延迟控制机制和应用窗口是变化的。
主要的实验设计沿着三个比较轴组织。首先，对于基于暂停的控制，比较了固定持续时间和备份完成窗口。其次，对于CPU份额控制，比较了使用相同cpu.weight=1设置的CFS和SCX之间的调度器层。第三，对于CPU并行度限制，比较了固定持续时间和备份完成窗口。除了这三个比较轴之外，研究还包括对代表性样本的初步敏感性分析，以检查对固定参数设置的依赖性，以及一个良性工作负载评估，以评估操作副作用和实际部署能力。
表3总结了勒索软件实验中使用的主要延迟控制条件。备份完成窗口从确定备份目标后开始应用延迟控制，直到该目标的备份生成完成。固定持续时间窗口在打开检测时开始延迟控制，并在预定持续时间后释放它。当连续观察到对受保护文件的访问时，这些应用将相应地重复。
在这些条件中，基于调度的控制仅在备份完成窗口下进行评估。这是因为CPU份额控制的主要目的是在备份完成之前抑制加密吞吐量，从而为备份创建确保时间缓冲。在SCX条件下，scx_flatcg提前启动，并在整个实验过程中保持sched_ext启用，以便观察到的差异主要归因于调度器层。
评估使用CovB、EwB和PreB进行。特别是，本研究关注的是备份被创建但未能跟上加密目标的情况（高CovB但低EwB），以及备份数量增加但许多备份不对应于加密目标的情况（低PreB）。这些指标使得可以讨论CFS和SCX之间的CPU分配差异如何影响时间尺度重新配置。初步敏感性分析和良性工作负载评估分别呈现，因为它们具有互补的目的：前者澄清了参数依赖性，而后者澄清了在合法工作负载下的部署能力。
C. 检测模型
本研究采用了之前ROFBS工作中使用的检测器，并将相同的配置应用于ROFBS和ROFBS-TSR。因为主要目标是比较延迟控制机制，所以检测器的训练过程和超参数与之前的工作保持一致，本研究没有进行重新调整。
作为检测器输入使用的文件操作特征是通过eBPF收集的。具体来说，使用kprobes获取读/写相关信息，而使用kretprobes获取其他事件（如重命名）的相关信息。表4列出了本研究中钩住的内核函数及其相应的行为。
只有用于检测的信息被选择并以日志形式存储。具体来说，记录的字段包括时间戳、每个进程的累积读写量、删除次数、重命名次数和文件打开事件次数。虽然kprobes/kretprobes可以捕获广泛的信息，如函数参数和返回值，但收集不用于检测的特征可能会不必要地增加系统资源消耗。因此，收集的字段仅限于检测所需的信息。
在积累了足够的日志后，系统进入决策阶段。在决策阶段，日志不一定按时间排序，同一个PID的多个日志可能会几乎同时发生，这在没有预处理的情况下难以解释排序关系。因此，首先根据时间戳对日志进行排序，以建立时间顺序序列。接下来，将同一PID在短时间内产生的日志通过汇总读写次数聚合为单个事件，以减少过度碎片化。然后，将相邻日志的读写量附加到每个条目中，并将结果序列解析为适合输入检测模型的统一表示形式。决策阶段的整体流程如算法1所示。
算法1. 判断阶段（日志解析和推理）算法
1: data_parser (target_logs)
2: 加载模型。
3: 根据时间对target_logs进行排序。
4: 如果在某个时间窗口内存在来自同一PID的日志，则
5: 将它们视为同一事件并累积读写次数。
6: 否则
7: 将日志信息（例如，时间、PID、累计读写次数）添加到parsed_data中。
8: end if
9: 对于每个日志，还将之前和之后的读写信息添加到parsed_data中。
10: 对parsed_data进行预测并存储结果。
11: 对于每个结果pred，执行
12: 保存每个日志的PID和决策结果。
13: end for
14: 如果判断为恶意，则
15: 触发该进程及其子进程的响应。
16: end if
17: end function
用于训练和测试的特征日志是在与本研究中使用的实验环境不同的环境中收集的。从勒索软件和良性软件的执行中获得的日志按照算法1组织成伪时间序列。为了评估对未见过的勒索软件家族的泛化能力，Monti、REvil和LockBit被视为未见过的家族，而其余的勒索软件家族被包含在训练数据中。良性日志来自常见的良性活动，包括使用tar和zip进行文件归档，以及常规的shell命令，如ls和cd。
一些勒索软件家族在执行过程中会生成多个子进程，如果仅使用PID计算累积统计信息，则活动跟踪会不准确。为了解决这个问题，本研究在收集日志时使用PPID进行关联，以便可以将子进程的活动作为同一谱系的一部分进行跟踪。
要运行检测器，需要配置四个参数：(i) 触发停止操作所需的恶意决策总数，(ii) 判断输出为恶意的决策阈值，(iii) 作出决策所需的日志数量，以及(iv) 将多个日志视为同一事件的时间宽度。本研究采用了与先前工作相同的参数值。具体来说，恶意决策总数设置为5，恶意决策阈值设置为0.8，所需日志数量设置为150，事件聚合时间宽度设置为370毫秒。
表5报告了组成ML算法的检测性能。分类器使用scikit-learn的默认设置进行训练，没有进行额外的超参数调整。在以下实验中，所有控制方法都使用相同的检测模型，以便观察到的差异可以归因于延迟控制机制而不是检测器的变化。
表5 机器学习中使用的算法及其检测性能。
混淆矩阵如表6所示。
真正例（TP）：正确分类为恶意的恶意日志数量。
假正例（FP）：错误分类为恶意的良性日志数量。
假负例（FN）：错误分类为良性的恶意日志数量。
表6 RF分类器的混淆矩阵。
表7 敏感性分析（计数）：Conti和Sodinokibi的参数设置。
实验1：暂停窗口设计（固定持续时间与备份完成窗口）
本实验关注基于暂停的延迟控制，并评估应用程序窗口的选择如何影响备份跟踪。暂停可以直接抑制加密进度。然而，延迟的持续时间强烈影响有效性和副作用，例如过度阻塞或过早释放。因此，本实验比较了固定持续时间窗口和备份完成窗口，以明确哪种设计在勒索软件行为多样性下能提供更稳定的跟踪改进。
所有实验设置在不同条件下保持一致，包括受保护的数据集、受保护的路径、开放触发配置、备份生成逻辑和检测器配置。唯一变化的变量是基于暂停控制的应用程序窗口。在发生开放事件时，会识别发出开放的实体的PID和PPID，并对两者应用暂停控制。在固定持续时间窗口中，PID/PPID在检测到开放后立即暂停，并在预定的暂停时间Wpause后恢复。在本研究中，Wpause设置为3秒。在备份完成窗口中，PID/PPID在检测到开放后立即暂停，并在该开放事件触发的备份生成完成后恢复。这种设计允许直接比较窗口设计的权衡：固定持续时间窗口可能会过早释放（延迟不足），或者在备份完成后保留不必要的延迟；而备份完成窗口可以自适应地确保所需的延迟，但可能会增加暂停次数和总暂停时间。
实验2：调度器层（Cfs与Scx）
本实验隔离了调度器层对CPU共享控制下的加密节流和跟踪的影响。使用cgroup v2和cpu.weight进行CPU共享控制可以减少分配给加密过程的CPU时间，从而降低加密吞吐量。然而，实际的分配行为可能取决于调度器的实现。因此，本实验将cpu.weight固定为1，并将应用程序窗口固定为备份完成窗口，从而使调度器层（CFS与SCX）成为主要独立变量。
在CFS条件下，检测到开放时，PID/PPID被移动到一个专用的cgroup中，应用cpu.weight=1并保持到备份完成，然后将进程移回原始cgroup。在SCX条件下，在实验开始前启动scx_flatcg以启用sched_ext，并在整个实验过程中保持启用状态。与CFS条件相同的cgroup控制（迁移到专用cgroup，cpu.weight=1，并在备份完成后释放）在检测到开放后应用。这种设计允许将观察到的差异主要归因于调度器层。
实验3：CPU并行性节流（固定持续时间与备份完成窗口）
本实验通过cpuset评估CPU并行性节流，并检查应用程序窗口如何影响跟踪。现代勒索软件可以通过高度并行的加密在短时间内破坏大量文件。因此，限制CPU并行性可以直接作为减少加密进度的手段。同时，限制的激活时间和持续时间决定了跟踪改进与性能影响之间的权衡。因此，本实验比较了固定持续时间窗口和备份完成窗口，以明确哪种设计在实践中更合适。
在固定持续时间窗口中，PID/PPID在检测到开放后立即被限制在一个CPU核心上，并在预定的时间Wcpu后恢复。在备份完成窗口中，同样的单核限制在检测到开放后立即应用，并保持到相应的备份生成完成。与其他实验一样，数据集、受保护的路径、开放触发、备份逻辑和检测器配置在不同条件下保持一致。
实验4：良性工作负载影响
本实验评估延迟控制对良性工作负载的影响，并研究其对实际部署性的影响。为此，在相同的Linux实验环境中添加了两个合法的加密相关工作负载：使用GPG进行文件级加密和将文件复制到LUKS挂载的加密卷。选择LUKS是因为Linux内核文档将其描述为基于dm-crypt的磁盘加密的推荐接口，而GPG被广泛用作基于OpenPGP的加密和签名的合法用户空间工具[40]、[41]。
在这些运行中，检测器及其相关控制逻辑在与勒索软件实验相同的监控配置下保持启用。这种设计使我们能够检查良性工作负载是否被错误标记，以及延迟控制机制相对于无延迟控制的情况引入了多少开销。与其他实验一样，每个条件独立执行了五次，并使用平均值和标准差总结了执行时间。
H. 指标
为了分别评估备份的可行性和加密目标的跟踪，本文定义了基于计数的量和基于唯一基名的比率指标。与勒索提示相关的辅助文件（例如，类似README的文件）从所有计数中排除。
定义了四个计数变量如下：
NE：加密的唯一基名数量（加密文件计数）。
NB：备份创建成功的唯一基名数量（备份计数）。
NEB：有相应备份的加密基名数量（带备份的加密计数）。
NS：进入备份处理管道的唯一基名数量（在确定目标时计数）。
基于这些计数，定义了三个比率指标。它们以百分比的形式报告；因此，在呈现结果时应用了100的因子。
CovB = NB / NS (6) 表示成功备份的数量占进入处理的尝试的数量比例。
EwB = NEB / NE (7) 表示被相应备份覆盖的加密目标的比例。当NE=0时，EwB因除以零而未定义，视为N/A。
PreB = NEB / NB (8) 表示生成的备份中对应于加密目标的比例。当NB=0时，PreB因除以零而未定义，视为N/A。
这三个指标并不将备份有效性简化为一个单一值；相反，它们分别捕获了可行性、覆盖率和精确度。因此，应结合绝对计数NE、NS、NB和NEB来解释这些指标。例如，高CovB与低EwB表明正在生成备份，但未能跟上加密目标的步伐；而低PreB表明许多生成的备份不对应于最终的加密输出。因此，结果表设计为同时使用比率指标和相应的计数来读取，以便在不同控制条件下区分主要的失败模式。
第六节 结果
本节报告了没有延迟控制的ROFBS的结果，作为基线，以及三个TSR实验：实验VI-C（暂停窗口设计：固定持续时间与备份完成窗口），实验VI-D（调度器层：CFS与SCX在cpu.weight=1下），以及实验VI-E（通过cpuset进行CPU并行性节流：固定持续时间与备份完成窗口）。它还报告了实验VI-F的结果，该实验评估了GPG和LUKS对良性工作负载的影响。
在所有表格中，NE、NS、NB和NEB表示唯一基名的计数，而CovB、EwB和PreB以百分比的形式报告。当NE=0时，EwB报告为N/A，因为它未定义。对于所有实验条件，进行了五次独立运行，本节表格中报告的值是每次运行的平均值。此外，还报告了指标的标准差，以显示单次运行无法捕获的变异性。这使得从可重复性的角度来看，跨条件的比较更加合适。尽管NE、NS、NB和NEB是基于唯一基名的计数量，但在这里它们作为每次运行的平均值报告。同样，CovB、EwB和PreB也与其在独立运行中的变异性一起报告。
A. 参数选择的初步敏感性分析
为了检查固定参数设置的敏感性，使用Conti和Sodinokibi进行了初步敏感性分析。对于cpu.weight，评估了三个值：1、10和50。对于Wpause和暂停间隔，评估了三个值：1秒、3秒和10秒。当一个参数发生变化时，其余参数保持不变，具体设置为：cpu.weight=1，Wpause=3秒，以及suspend interval=3秒。额外的分析表明，改变cpu.weight的效果有限。在当前的实验范围内，仅依靠CPU份额控制不足以重建足够的时间缓冲。相比之下，改变suspend interval的效果更为显著，尽管改进的程度取决于勒索软件的类型，并且不是单调的。对于Conti来说，3秒或更长的suspend interval显著提高了加密目标的覆盖率。对于Sodinokibi，3秒时获得了最高的EwB值，而在10秒时没有进一步的改进。这些结果表明，暂停的效果不仅取决于暂停的持续时间本身，还取决于第一个受保护文件被打开的时间、暂停窗口与加密初始阶段的重叠程度，以及备份和检测过程在该时间段内能取得的进展。因此，TSR的有效性不应被理解为单一参数的单调函数，而应理解为特定于勒索软件的加密动态与系统侧动态相互作用的结果。基于这一初步分析，主要实验是在cpu.weight=1，Wpause=3秒，以及suspend interval=3秒的条件下进行的。
B. 基线：ROFBS（无延迟控制）
在基线条件下，ROFBS在检测到文件打开时立即创建备份，不对加密进度施加任何延迟控制（表3）。这一条件用于评估在没有TSR干预的情况下ROFBS跟踪加密情况的能力。表9总结了实验结果。
表8 敏感性分析（指标）：Conti和Sodinokibi的参数设置。
表9 基线结果（ROFBS无延迟控制，五次运行的平均值±标准差）。
对于Conti，CovB和EwB都约为90%，表明在这种工作负载下ROFBS能够很好地跟上加密的进度。相比之下，AvosLocker生成的备份数量很多（NB=42），但与加密目标的重叠很少（NEB=3），导致EwB仅为12.50%和PreB为7.14%。这表明大量的备份工作被浪费在最终并未对应于加密目标的文件上，这在高吞吐量情况下会加剧积压的增长。对于Sodinokibi，NB=3且CovB=5.17%，都表明备份完成经常发生在加密/删除之前。对于HelloKitty，CovB虽然不为零，但NEB为0，导致EwB为0%，这表明虽然创建了备份，但并未覆盖加密目标。IceFire也显示出类似的低EwB值，表明在没有延迟控制的情况下，ROFBS无法稳健地维持跟踪。
C. 实验1：暂停窗口设计（固定持续时间与备份完成窗口）
实验1评估了基于暂停控制的窗口设计对跟踪效果的影响。表10和表11分别报告了计数和比率指标。由于暂停可以影响加密开始的时间以及勒索软件的进展速度，因此绝对计数（NE和NS）在不同条件下可能会有所变化。因此，结果需要通过比率和计数来综合解读。
表10 实验1（计数）：固定暂停窗口与备份完成窗口。
表11 实验1（指标）：固定暂停窗口与备份完成窗口。
对于Conti，备份完成窗口的跟踪效果优于固定持续时间窗口。具体来说，备份完成窗口实现了EwB=85.00%，NEB为17（总目标数NE=20），而固定持续时间窗口的EwB为55.56%，NEB为5（总目标数NE=9）。这表明，在此家族的勒索软件行为下，保持暂停直到备份完成可以更一致地保持加密目标的覆盖率。
相比之下，Sodinokibi和IceFire在固定持续时间窗口下表现更好。对于Sodinokibi，固定持续时间窗口下的NEB为12，而备份完成窗口下的NEB为3，导致CovB和EwB都更高。对于IceFire，固定持续时间窗口下的EwB为50.00%，NEB为4（总目标数NE=8），而备份完成窗口下的EwB为21.43%，NEB为3（总目标数NE=14）。Monti也显示出相同的趋势，固定持续时间窗口下的CovB和EwB都高于备份完成窗口。这些结果表明，对于某些勒索软件行为，即使是在固定持续时间下，引入足够强的延迟也可能比将延迟与备份完成同步更有效。尽管AvosLocker在不同运行中的绝对计数有所变化，但总体模式是稳定的：重叠要么不存在，要么可以忽略不计，且观察到的异常情况更符合早期抑制的情况，而不是成功跟踪的情况。
AvosLocker在固定持续时间窗口下NE为0，导致EwB无法定义。在这种情况下，虽然生成了备份文件，但没有观察到加密输出。这种模式表明早期干预可能在受保护用户数据被加密之前就抑制了可观察到的加密进度。相比之下，在备份完成窗口下，AvosLocker显示出大量的NE，但没有重叠，表明仅依赖于备份完成的暂停不足以维持对这种勒索软件的加密目标覆盖。
D. 实验2：调度器层（Cfs与Scx）
实验2通过将cpu.weight设置为1并在备份完成窗口内施加控制，来隔离调度器层对CPU份额限制的影响。表12和表13报告了实验结果。即使在相同的cpu.weight设置下，CFS和SCX之间也存在显著差异。
表12 实验2（计数）：调度（CFS + cgroup）与调度（SCX + scx_flatcg + cgroup）。
表13 实验2（指标）：调度（CFS + cgroup）与调度（SCX + scx_flatcg + cgroup）。
最明显的差异出现在Conti上。在CFS下，备份几乎从未成功完成，NB为1（总目标数NS=47），导致CovB为2.13%和EwB为0%。在SCX下，几乎所有观察到的目标都成功完成了备份，NB为19（总目标数NS=19），加密目标覆盖率也很高，NEB为18（总目标数NE=18），导致CovB为100.00%和EwB为100.00%。这表明，在使用CPU份额控制时，调度器层可以是TSR效果的决定性因素。
Monti也显示出相同的趋势。在CFS下，备份几乎从未成功完成，CovB为2.17%和EwB为0%。在SCX下，备份的可行性和加密目标覆盖率都接近完美，CovB为100.00%和EwB为100.00%。总体而言，Conti和Monti表明调度器的选择可以决定基于CPU份额的TSR是否成功。对于Conti和Monti，CFS和SCX之间的差异远大于实验间的变化，这支持了调度器选择可以决定基于CPU份额的TSR是否成功的定性结论。
Sodinokibi也从SCX中受益，尽管改进幅度较小。与CFS相比，SCX将NB从5增加到15，NEB从5增加到15，CovB从7.81%增加到35.71%，EwB从13.51%增加到40.54%。这表明，当加密吞吐量受到CPU竞争的强烈影响时，有效的cgroup权重到CPU分配的映射可以提高跟踪效果。
相比之下，AvosLocker在两种调度器设置下都难以保护。即使在SCX下，重叠也非常小，NEB为1（总目标数NE=75），导致EwB为1.33%和PreB为1.96%。HelloKitty在两种调度器下NEB始终为0，表明备份文件被创建但未覆盖任何加密目标。IceFire也表现出类似的低EwB值，表明在没有延迟控制的情况下，ROFBS无法稳健地维持跟踪。
E. 实验3：CPU并行性限制（固定持续时间与备份完成窗口）
实验3通过cpuset评估了CPU并行性的限制，并比较了固定持续时间窗口和备份完成窗口的效果。表14和表15报告了实验结果。总体而言，基于cpuset的限制在不同样本中的效果参差不齐，应用窗口的选择并不能带来统一的改进。
表14 实验3（计数）：CPU并行性（cpuset，固定）与CPU并行性（cpuset，备份完成窗口）。
表15 实验3（指标）：CPU并行性限制（cpuset，固定）与CPU并行性（cpuset，备份完成窗口）。
对于Conti，两种窗口设计下的CovB和EwB都较低。固定持续时间窗口下的重叠略优于备份完成窗口，EwB为2.33%对比0.00%，但总体效果仍然有限。对于Sodinokibi，两种设计下的CovB都较低，备份完成窗口下的加密目标覆盖率略高于固定持续时间窗口，EwB为11.11%对比8.82%。
AvosLocker在两种设置下都难以保护。尽管生成了大量备份文件，但没有与加密目标的重叠，EwB和PreB都接近零。HelloKitty在两种窗口下NEB始终为0，表明仅靠cpuset限制无法恢复加密目标的覆盖率。观察到与README_TO_RESTORE和临时文件相关的文件，表明工作流程至少进展到了中间阶段。然而，无法建立打开时捕获的备份目标与最终加密输出之间的一一对应关系。这种模式更符合目标映射不匹配的情况，而不是简单的备份延迟。
Revil在两种设置下也难以保护，固定持续时间窗口下的重叠有限，备份完成窗口下的重叠为零。LockBit在两种条件下的NB均为0，表明单独的暂停无法恢复这种样本的备份可行性。
F. 实验4：对良性工作负载的影响
实验4评估了延迟控制对良性工作负载的影响。考虑的良性工作负载包括将文件复制到LUKS挂载的加密卷以及使用GPG进行文件级加密。表16和表17报告了这两种工作负载的执行时间、相对于基线的相对开销以及完成状态。两种工作负载在所有条件下都完成了。
表16 良性LUKS工作负载的执行时间开销。
表17 良性GPG工作负载的执行时间开销。
Suspend（固定）对两种工作负载都造成了最大的开销。对于LUKS工作负载，执行时间达到了1980.184±361.222秒；对于GPG工作负载，执行时间达到了6076.710±0.333秒，相对于基线分别慢了3210.24%和5630.04%。相比之下，Suspend（备份完成窗口）在LUKS工作负载上的开销接近基线，在GPG工作负载上仅引入了相对较小的开销。
Scheduling（CFS + cgroup）在LUKS工作负载上接近基线，但在GPG工作负载上引入了57.27%的延迟。相比之下，Scheduling（SCX + scx_flatcg + cgroup）在LUKS工作负载上引入了35.56%的延迟，在GPG工作负载上引入了14.92%的延迟，表明调度器控制对两种工作负载都有中等程度的影响。
这些结果表明，调度器控制的效果强烈依赖于具体的方法和工作负载。
CPU并行性控制也根据配置的不同而表现出不同的行为。CPU并行性（cpuset，备份完成窗口）在LUKS工作负载上引入了50.90%的延迟，在GPG工作负载上引入了7.33%的延迟。相比之下，CPU并行性（cpuset，固定）在LUKS工作负载上接近基线，在GPG工作负载上仅引入了6.53%的延迟。
VII. 讨论
本节讨论了何时以及为何时间尺度重新配置是有效的，以ROFBS无延迟控制作为参考（表9）。讨论围绕四个实验轴展开：基于暂停的定时干预（实验1）、在CPU份额控制下的调度器层效应（实验2）、通过cpuset进行CPU并行性限制（实验3）以及对良性工作负载的影响（实验4）。除了比率指标CovB、EwB和PreB之外，还强调了绝对计数NE、NS、NB和NEB。这一点很重要，因为相同的比率可能源于质量上不同的情况，例如加密几乎没有进展的情况（NE较小）和加密大规模进展的情况（NE较大）。在这里，CovB反映了相对于观察到的备份目标的备份完成可行性，EwB反映了加密目标的覆盖情况，而PreB反映了备份的精确度。通过联合解释比率和计数，可以区分以下情况：(i) ROFBS-TSR有效的情况，因为加密被减慢或抑制；(ii) 备份被生成但不对应于加密目标的情况；以及 (iii) 在基本时间尺度不匹配的情况下，防御完全跟不上攻击的情况。由于报告的值是五次独立运行的平均值，以下讨论强调的是在多次运行中保持稳定的定性趋势。当标准差相对较大时，解释应理解为一种趋势，而不是方法之间的严格排名。
**实验1：暂停窗口设计（固定持续时间与备份完成窗口）**
实验1比较了两种基于暂停的延迟控制窗口设计（计数：表10；指标：表11）。结果表明，暂停的有效性不仅取决于是否应用了暂停，还取决于在早期阶段保证了多少延迟，以及之后加密的连续性和积极性。换句话说，窗口设计决定了在基本时间尺度不匹配会占主导地位的关键时刻是否创造了时间缓冲。Conti展示了在加密持续进行时保持暂停直到备份完成的优势。在固定持续时间窗口下，NE=9.4±1.8，NB=6.8±2.0，NEB=5.8±2.0，得出CovB=64.61±9.99%和EwB=60.65±11.37%。在备份完成窗口下，NE=20.0±1.9，NB=18.2±0.8，NEB=17.2±0.8，得出CovB=87.29±9.41%和EwB=85.88±10.17%。这表明，对于像Conti这样的家族来说，保持暂停活动直到备份完成可以更可靠地保持时间缓冲并维持加密目标的覆盖。相比之下，Sodinokibi、IceFire和Monti在固定持续时间窗口下表现更好。对于Sodinokibi，固定持续时间窗口下CovB=23.48±18.13%和EwB=26.64±11.45%，而备份完成窗口下CovB=6.05±2.42%和EwB=10.34±3.56%。对于IceFire，固定持续时间窗口下EwB=70.47±31.44%，而备份完成窗口下EwB=26.94±5.74%。Monti也显示出相同的趋势，固定持续时间窗口下CovB=82.14±20.82%和EwB=79.84±23.18%，相比之下备份完成窗口下CovB=54.62±25.36%和EwB=52.84±26.23%。这些结果表明，对于某些勒索软件行为，即使在固定持续时间下引入足够强的延迟，也可能比将延迟持续时间同步到备份完成更有效。
尽管AvosLocker的绝对计数在多次运行中有所不同，但定性模式是稳定的：重叠要么不存在，要么可以忽略不计，观察到的异常情况更符合早期抑制而不是成功跟踪。AvosLocker在固定持续时间窗口下显示NE=0，这使得EwB无法定义。同时，备份仍然被创建（NB=18），但没有一个备份对应于加密目标（NEB=0，因此PreB=0%）。先前的分析报告称AvosLocker首先放置README_FOR_RESTORE，然后启动加密线程，最后附加.avoslinux扩展名[42]。在我们的检查中，在固定持续时间窗口下，README_FOR_RESTORE存在，原始文件和备份文件都保留了下来，但没有观察到带有.avoslinux扩展名的文件。这种模式更符合在勒索信息放置和基于线程的加密之间的早期阶段实施延迟控制的情况，而不是简单的备份延迟。相比之下，在备份完成窗口下，AvosLocker显示出较大的NE，但重叠为零，表明仅与备份完成相关的暂停不足以维持针对该家族的加密目标覆盖。
HelloKitty在两种窗口下都很难对付，整个过程中NEB=0。观察到与README_TO_RESTORE和临时文件相关的异常情况，表明工作流程至少进展到了中间阶段。Unit 42和VMware的分析也表明HelloKitty在最终建立加密文件之前引入了特定于样本的文件名转换，涉及临时文件和勒索信息相关的输出[43]、[44]。然而，在我们的观察中无法建立打开时捕获的备份目标与最终加密输出之间的一一对应关系。综合来看，这种模式更符合特定于家族的目标映射不匹配，而不是简单的备份延迟。
Revil也很难对付，在固定持续时间窗口下重叠有限，在备份完成窗口下重叠为零。LockBit在两种条件下都显示NB=0，表明仅靠暂停不足以恢复该样本的备份可行性。
总体而言，实验1表明暂停是一个强大的TSR工具，但最佳窗口设计并非通用。固定持续时间窗口还是备份完成窗口更可取，取决于勒索软件的行为、首次观察到的打开事件的性质以及备份完成时间的分布。这表明TSR应该被视为一个控制设计问题，而不是一种适用于所有情况的机制。
**实验2：调度器层（Cfs与Scx）**
实验2比较了在两种调度器层CFS和SCX下基于CPU份额的节流，同时固定cpu.weight=1并使用备份完成窗口（计数：表12；指标：表13）。结果表明，相同的cgroup权重配置可能导致显著不同的实际节流效果，这意味着调度器层可能是实际是否能够重建时间缓冲的决定性因素。在Conti和Monti中这一差异最为明显。对于这两个样本，CFS导致备份完成几乎完全失败，而SCX则几乎完全恢复了可行性和加密目标的覆盖。在Conti中，CFS下NE=46.4±2.1，NS=47.4±2.1，NB=1.4±0.5，NEB=0.4±0.5，得出CovB=2.94±1.10%和EwB=0.84±1.16%。在SCX下，NE=18.0±0.0，NS=19.0±0.0，NB=19.0±0.0，NEB=18.0±0.0，得出CovB=100.00±0.00%和EwB=100.00±0.00%。Monti也显示出从CFS下的几乎完全失败到SCX下的几乎完全覆盖的转变。对于Conti和Monti来说，CFS和SCX之间的对比远大于观察到的运行间变化，这支持了调度器选择可以决定基于CPU份额的TSR是否成功的定性结论。
Sodinokibi也从SCX中受益，尽管效果不那么显著。与CFS相比，SCX提高了CovB和EwB，同时保持PreB=100.00±0.00%。这表明，当CPU竞争对加密吞吐量有足够影响时，调度器层可以改变cgroup权重如何转化为实际的节流和跟踪性能。相比之下，即使使用SCX，AvosLocker、HelloKitty、Revil和LockBit在CPU份额控制下仍然难以对付。AvosLocker仍然几乎没有重叠，HelloKitty的NEB保持为0，Revil仅略有改善，LockBit完全没有成功的备份。这些情况表明，当加密进展主要不受CPU份额限制，或者主要的不匹配来自目标映射而不是定时时，仅靠资源分配是不够的。
IceFire提供了一个说明为什么必须联合解释比率指标的例子。在SCX下，CovB上升到89.64±16.39%，表明大多数观察到的目标可以完成备份。然而，EwB在多次运行中保持未定义或接近零，表明这种可行性的提高并没有转化为加密目标的稳定覆盖。同样重要的是要注意，在这个实验中SCX是全局启用的。因此，CFS和SCX之间的观察到的差异不应仅解释为勒索软件方面的节流效果。备份路径和检测器相关的处理在SCX下也可能收到与CFS不同的调度服务。因此，观察到的差距应解释为当前设置下的端到端调度器层效应，而不仅仅是勒索软件的副作用。
总体而言，实验2表明基于调度器的节流可以非常有效，但仅适用于部分样本。其成功取决于CPU分配是否是主要瓶颈，以及调度器层如何影响加密进展、备份完成和检测器进展之间的端到端平衡。
**实验3：CPU并行性限制（固定持续时间与备份完成窗口）**
实验3使用cpuset评估了CPU并行性限制，并比较了固定持续时间窗口和备份完成窗口（计数：表14；指标：表15）。结果表明，在特定情况下，限制CPU并行性可以提高覆盖率，但它并不是一个在所有样本中都可靠的TSR工具。对于Conti来说，cpuset节流基本上无效。两种窗口设计都产生了非常低的可行性和覆盖率，备份完成窗口将重叠减少到零。这表明，当主要约束不是由CPU核心并行性控制时，限制CPU并发性不足以重建足够的时间缓冲。
Sodinokibi在cpuset控制下仅显示出有限的恢复。备份完成窗口的表现略优于固定持续时间窗口，但两者都远低于稳健跟踪所需的水平。这表明，仅限制并行性不足以克服该样本中的主要瓶颈。
AvosLocker、HelloKitty、Revil和LockBit在两种cpuset设置下都很难对付。AvosLocker仍然产生许多备份但没有重叠，HelloKitty的NEB保持为0，Revil也保持为零重叠，LockBit完全没有成功的备份。这些情况表明，当主要瓶颈与目标映射、文件替换行为或备份方面的可行性有关时，仅靠CPU并行性控制不足以恢复跟踪。
IceFire和Monti提供了有用的对比。对于IceFire，固定持续时间窗口产生少量重叠，而备份完成窗口则没有重叠。对于Monti来说，备份完成窗口显著提高了可行性和加密目标的覆盖率。这些差异表明，cpuset的实用性强烈依赖于并发性是否实际上是评估样本中损害扩展的主要驱动因素。同时，cpuset的效果不如实验2中观察到的调度器层效果稳定。特别是，对于某些样本的明显改善应被视为有条件的，而不是普遍可复制的，因为在基于cpuset的控制下运行间的变化更大。
**实验4：对良性工作负载的影响**
实验4的结果表明，操作副作用对良性工作负载的影响很大程度上取决于延迟控制方法和工作负载类型。如表16和表17所示，LUKS工作负载和GPG工作负载在所有条件下都完成了，没有观察到良性任务无法在此评估范围内完成的案例。同时，执行时间在不同条件下有很大差异，Suspend（固定）对两种工作负载都造成了最大的开销。这表明，从对良性工作负载的影响角度来看，持续启用强基于暂停的控制在实践中难以证明其合理性。
相比之下，Suspend（备份完成窗口）在LUKS工作负载上接近基线，并且对GPG工作负载只引入了相对较小的开销。这表明，即使在基于暂停的控制下，根据实际备份进度限制控制持续时间也可以显著减少操作副作用。基于调度器的方法显示出不同的趋势。调度（CFS + cgroup）在LUKS工作负载上接近基线，但对GPG工作负载引入了相对较大的开销。相比之下，调度（SCX + scx_flatcg + cgroup）对两种工作负载都产生了中等开销，表明调度器层对良性工作负载的影响也取决于工作负载。这项结果表明，基于调度器的控制的实际效用不能仅从其对抗勒索软件的效果来评判，还应该考虑其对良性工作负载的副作用。CPU并行性控制根据应用窗口的不同也表现出不同的行为：对于两种工作负载，CPU并行性（cpuset，固定值）的影响相对较小；而CPU并行性（cpuset，备份完成窗口）对LUKS工作负载则造成了更大的开销。这表明限制并行性的成本并不固定，而是随着限制的持续时间和工作负载的性质而变化。总体而言，从良性工作负载的角度来看，TSR的实际部署能力不能通过任何单一的控制方法来统一确定。对于正常操作，如“暂停（备份完成窗口）”和相对较轻的CPU并行性控制是可行的选择；而更强的控制措施（如“暂停（固定值）”则更适合在高风险时期或检测到恶意行为后使用。然而，对这种分阶段操作策略的定量评估超出了本文的范围，留待未来的研究。
E. 局限性
所提出的机制并不依赖于基于虚拟机的部署，仅依赖于标准的Linux内核机制。不过，当前的评估是在Windows 11主机上运行的AlmaLinux虚拟机中进行的。由于测量数据是在虚拟化环境中获得的，因此无法完全排除主机端虚拟化堆栈对sched_ext行为、eBPF钩子延迟以及CFS和SCX之间观察到的差异的影响。因此，本文中报告的调度器层比较应被视为在当前虚拟化设置下的观察结果，而在裸机硬件上的复现工作仍需未来完成。
在实验2中，scx_flatcg在整个实验过程中始终保持启用状态。因此，观察到的CFS和SCX之间的差异不应仅仅解释为对勒索软件进程的节流效果。备份过程和检测相关处理在SCX下可能也会收到与CFS不同的调度服务。因此，观察到的差距应被视为当前设置下的端到端调度器层效应。当前实验并未完全区分这一差距是由于加密抑制作用更强还是由于备份和检测的调度服务不同所致。对备份路径的更独立评估仍是未来的研究课题。
F. 总体意义
在所有实验中，提高跟踪效果的关键在于早期且足够强的干预，以防止基本时间尺度不匹配自我放大。基于暂停的定时干预可以非常有效，但其窗口设计决定了时间松弛是否能够可靠地重建或过早释放。基于资源的控制也可以有效，但调度器层会显著影响控制参数如何转化为实际的节流效果。CPU并行性节流在并发主导的情况下有帮助，但并非普遍适用。最后，尽管有非零备份，仍然存在低重叠或零重叠（NEB=0）的持续案例，这表明除了减慢加密速度外，触发到目标的映射与备份文件的一致性同样重要。这一观察结果支持同时使用这三个指标和绝对计数：它们有助于区分可行性失败、定时失败和相关性失败，从而定位每种勒索软件行为下的主要瓶颈。结果还表明，尽管TSR对不同勒索软件样本的有效性并不统一，但通过受保护文件打开观察和延迟控制来重建时间尺度的设计原则仍具有一定程度的普遍性，可以应用于未见过的或新出现的勒索软件行为。然而，其有效性取决于是否能够实现早期干预，以及每个样本的主要瓶颈是否与选定的控制手段相匹配。此外，本文中对未见样本的证据基于检测器成功对Monti、Revil和LockBit等样本做出了停止决策的事实。因此，本研究并未评估检测器未能识别这些样本的情况。因此，这些结果不应被解释为普遍的零日保护证据，而应被视为在包括未知样本的更广泛条件下明确TSR的有效性和局限性的证据。
第八节 结论
本文提出了时间尺度重构（Time Scale Reconfiguration，简称TSR）框架，该框架通过干预加密进程的时间尺度来使实时备份能够跟上勒索软件的加密速度。TSR建立在实时打开文件备份系统（Real time Open File Backup System，简称ROFBS）的基础上，该系统在文件打开事件时创建备份。通过将加密进度与备份完成之间的时间冲突定义为基本时间尺度不匹配，该框架旨在不仅仅依赖更快的备份速度，而是通过延迟攻击方来重建时间松弛。为了实现这一框架，本文通过eBPF进行文件打开观察，并结合cgroup v2进行进程暂停、通过sched_ext进行调度器层控制以及通过cpuset进行CPU并行性控制来实施ROFBS TSR。在评估中，本文引入了CovB来衡量备份完成的可行性，EwB来衡量加密目标的覆盖范围，以及PreB来衡量备份的精确度，并将这些比率与相应的绝对计数一起解释，以便区分不同的失败模式。评估涵盖了多种Linux勒索软件样本，包括Sodinokibi、IceFire、HelloKitty、AvosLocker、Conti、Monti、Revil和LockBit，并使用五次独立运行的平均值和标准差进行了比较。结果表明：首先，基于暂停的控制是一种强大的TSR手段，但固定持续时间窗口和备份完成窗口的相对优势取决于具体样本，表明早期延迟和持续保护直到备份完成都很重要；其次，即使在相同的cpu.weight下，调度器层也会显著影响跟踪性能，SCX对Conti和Monti等样本有决定性的改进效果，而对其他样本的效果则较差；第三，通过cpuset进行CPU并行性控制仅对部分样本有用，不应被视为普遍有效的机制；其好处仅在CPU并发成为主要瓶颈时才显现；第四，良性工作负载的评估显示，持续启用的强暂停会带来极高的开销，而较轻的控制措施对某些工作负载的影响接近基线水平。此外，敏感性分析表明，在当前范围内改变cpu.weight的效果有限，而暂停间隔的影响更大，尽管其有效性仍取决于具体样本。
综上所述，这些发现表明TSR不应被理解为一种在所有勒索软件样本中都统一有效的单一控制机制。实际上，其有效性取决于勒索软件行为、触发时机、备份方面的进展以及检测生效的时间之间的相互作用。此外，尽管研究在包括未见样本的条件下显示出一定的普遍性，但这一结论是基于检测器成功对这些样本做出停止决策的前提。因此，本研究并不声称提供普遍的零日保护，而是明确了TSR在包括未知样本的更广泛条件下的有效性和局限性。
未来的工作方向包括：根据观察到的信号调整窗口设计和延迟幅度的自适应TSR；在裸机硬件上进行重新评估；以及更独立地分析调度器层对备份路径的影响。此外，还需要扩展对良性工作负载和整体系统吞吐量的副作用的定量评估，以制定平衡安全性和可用性的实际操作指南。
打赏
