应用程序白名单.

应用程序白名单(现称 allowlisting)颠覆了杀毒软件"默认放行"的模型:只有与已批准策略匹配的可执行文件、DLL、脚本和安装程序——按哈希、发行者签名或路径匹配——才被允许运行,其余一切都被阻止。Microsoft AppLocker 与 Windows Defender Application Control(WDAC)、Linux 的 fapolicyd、macOS 的公证(notarization)门禁,以及 Airlock Digital、ThreatLocker 等独立产品都实现了这一模式。NIST SP 800-167 指南记录了其架构,澳大利亚信号局(ASD)的 Essential Eight 将应用控制列为抵御定向入侵的首要缓解措施之一。

难点不在于阻止显而易见的恶意软件,而在于封堵绕过手法。攻击者滥用**"就地取材"二进制文件(LOLBins)**——如 mshta.exe、regsvr32.exe、msbuild.exe、installutil.exe 等由 Microsoft 签名并受信任的工具——来执行代码,而幼稚的白名单会因为加载器已签名而放行。为此 Microsoft 发布了一份 WDAC 推荐阻止规则清单来中和这些已知绕过,成熟的策略会强制启用 DLL 和脚本规则,而不仅是可执行文件规则,使得被允许的进程无法旁加载未签名的库或运行任意脚本。基于路径的规则最弱(一个用户可写的被允许目录即可击溃它);基于发行者和哈希的规则更强,但需要真正的变更管理,因为每次打补丁都会改变哈希,每个新工具都需要审批流程。

flowchart TD
  A[进程 / DLL / 脚本<br/>请求执行] --> B{是否匹配允许策略?}
  B -->|哈希匹配| C[允许]
  B -->|受信任发行者签名| C
  B -->|已批准路径| C
  B -->|无匹配| D[阻止 + 记录]
  C --> E{是否为已知<br/>LOLBin 绕过?}
  E -->|是,在阻止规则中| D
  E -->|否| F[运行]
  D --> G[告警 / 审批流程]

在"先审计后强制"模式下妥善运行时,白名单对无文件攻击、未签名勒索软件和不可信下载都非常有效——但前提是启用 DLL/脚本规则和推荐阻止规则,否则 LOLBins 会大摇大摆地从正门走进来。