implementing-application-whitelisting-with-applocker

# 使用 AppLocker 实施应用程序白名单

## 使用场景

在以下情况下使用本技能：
- 实施应用程序控制以防止 Windows 端点上未授权软件的执行
- 满足合规要求（PCI DSS 6.4.3、NIST 800-53 CM-7、ACSC Essential Eight）
- 阻断常见攻击向量：living-off-the-land 二进制文件（LOLBin）、基于脚本的攻击、未授权的管理工具
- 在信息亭、POS 或高安全环境中限制软件安装

**不适用于** macOS/Linux 应用程序控制（使用 Gatekeeper 或 AppArmor 等操作系统原生工具）或企业级 WDAC（Windows Defender Application Control）部署。

## 前置条件

- Windows 10/11 企业版或教育版，或 Windows Server 2016+
- 目标端点上已启用应用程序标识服务（AppIDSvc）
- 带有组策略管理控制台（GPMC）的 Active Directory
- 已审批软件的完整应用程序清单
- 带有代表性端点的测试 OU，用于策略验证

## 操作流程

### 步骤 1：清点已审批应用程序

在创建 AppLocker 规则之前，对所有合法软件进行编目：

```powershell
# 在参考端点上生成应用程序清单
Get-AppLockerFileInformation -Directory "C:\Program Files" -Recurse `
  -FileType Exe | Export-Csv "C:\AppLocker\app_inventory_progfiles.csv" -NoTypeInformation

Get-AppLockerFileInformation -Directory "C:\Program Files (x86)" -Recurse `
  -FileType Exe | Export-Csv "C:\AppLocker\app_inventory_progfiles86.csv" -NoTypeInformation

# 包括 Windows 系统可执行文件
Get-AppLockerFileInformation -Directory "C:\Windows" -Recurse `
  -FileType Exe | Export-Csv "C:\AppLocker\app_inventory_windows.csv" -NoTypeInformation
```

### 步骤 2：使用默认规则创建 AppLocker 策略

```powershell
# 在组策略编辑器（gpedit.msc）或 GPMC 中：
# 导航到：计算机配置 → 策略 → Windows 设置
#   → 安全设置 → 应用程序控制策略 → AppLocker

# 为每个规则集合启用默认规则：
# - 可执行规则：允许所有人运行 Program Files 和 Windows 中的文件
# - Windows Installer 规则：允许所有人运行经数字签名的 MSI
# - 脚本规则：允许所有人运行 Program Files 和 Windows 中的脚本
# - 打包应用规则：允许所有人运行已签名的打包应用

# PowerShell：生成默认规则
$defaultRules = Get-AppLockerPolicy -Local -Xml
Set-AppLockerPolicy -XmlPolicy $defaultRules -Merge
```

### 步骤 3：创建基于发布者的规则（推荐）

发布者规则是最易维护的，因为它们能在应用程序更新后继续生效：

```xml
<!-- 发布者规则的 AppLocker 策略 XML 示例 -->
<RuleCollection Type="Exe" EnforcementMode="AuditOnly">
  <!-- 默认：允许 Windows 二进制文件 -->
  <FilePublisherRule Id="a9e18c21-ff54-4677-b3ac-4b9a03261f6c"
    Name="允许 Microsoft 签名" Description="允许所有 Microsoft 签名的可执行文件"
    UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION*"
        ProductName="*" BinaryName="*">
        <BinaryVersionRange LowSection="*" HighSection="*"/>
      </FilePublisherCondition>
    </Conditions>
  </FilePublisherRule>

  <!-- 允许特定第三方供应商 -->
  <FilePublisherRule Id="b2e28c32-aa65-5788-c4bd-5c0b14372e7d"
    Name="允许 Adobe Acrobat" Description="允许 Adobe 签名的 Acrobat 可执行文件"
    UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=ADOBE INC.*"
        ProductName="ADOBE ACROBAT*" BinaryName="*">
        <BinaryVersionRange LowSection="*" HighSection="*"/>
      </FilePublisherCondition>
    </Conditions>
  </FilePublisherRule>
</RuleCollection>
```

### 步骤 4：阻断已知被滥用的二进制文件（LOLBin）

```powershell
# 针对常被滥用的 living-off-the-land 二进制文件的拒绝规则
# 这些是攻击者频繁使用的合法 Windows 工具

$denyPaths = @(
    "%SYSTEM32%\mshta.exe",
    "%SYSTEM32%\wscript.exe",
    "%SYSTEM32%\cscript.exe",
    "%SYSTEM32%\regsvr32.exe",
    "%SYSTEM32%\certutil.exe",
    "%SYSTEM32%\msbuild.exe",
    "%SYSTEM32%\installutil.exe",
    "%WINDIR%\Microsoft.NET\Framework\*\msbuild.exe",
    "%WINDIR%\Microsoft.NET\Framework64\*\msbuild.exe"
)

# 在 AppLocker 策略中为标准用户创建拒绝规则
# 重要：拒绝规则优先于允许规则
# 仅适用于标准用户（不适用于可能需要这些工具的管理员）
```

### 步骤 5：配置脚本规则

```
脚本规则（对于防止基于脚本的攻击至关重要）：

允许：
  - C:\Program Files\* 中的脚本（基于发布者或路径）
  - C:\Windows\* 中的脚本（默认 Windows 脚本）
  - 来自 \\fileserver\scripts\* 的已审批管理脚本

拒绝（针对标准用户）：
  - 来自用户可写目录的 PowerShell 脚本
  - 来自 %TEMP%、%APPDATA%、%USERPROFILE%\Downloads 的 VBScript
  - 来自任何用户可写位置的 JavaScript（.js）

DLL 规则（可选，对性能影响较大）：
  - 仅在高安全环境中启用
  - 允许来自 Program Files 和 Windows 目录的已签名 DLL
  - 性能影响：DLL 加载期间 CPU 使用率增加 5-10%
```

### 步骤 6：先在审计模式下部署

```powershell
# 关键：始终先在审计模式下部署 AppLocker，再切换到强制模式
# 审计模式记录将被阻断的内容，但不实际阻断

# 在 GPO 中将强制模式设置为"仅审计"：
# AppLocker → 可执行规则 → 属性 → 已配置：仅审计
# AppLocker → 脚本规则 → 属性 → 已配置：仅审计
# AppLocker → Windows Installer 规则 → 属性 → 已配置：仅审计

# 确保应用程序标识服务正在运行
Set-Service -Name AppIDSvc -StartupType Automatic
Start-Service AppIDSvc

# 将 GPO 链接到测试 OU
New-GPLink -Name "AppLocker-Audit-Policy" `
  -Target "OU=AppLocker-Pilot,DC=corp,DC=example,DC=com"

# 监控审计日志 2-4 周
# 事件日志：应用程序和服务日志 → Microsoft → Windows → AppLocker
# 事件 ID：
#   8003 = EXE/DLL 将被阻断
#   8006 = 脚本/MSI 将被阻断
#   8023 = 打包应用将被阻断
```

### 步骤 7：分析审计日志并优化规则

```powershell
# 导出 AppLocker 审计事件
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/EXE and DLL" `
  -FilterXPath "*[System[EventID=8003]]" |
  Select-Object TimeCreated,
    @{N='User';E={$_.Properties[0].Value}},
    @{N='FilePath';E={$_.Properties[1].Value}},
    @{N='FileHash';E={$_.Properties[4].Value}} |
  Export-Csv "C:\AppLocker\audit_blocked_exes.csv" -NoTypeInformation

# 检查被阻断的应用程序
# 对于每个被阻断的合法应用程序：
#   1. 创建发布者规则（如已签名）或路径规则（如未签名）
#   2. 添加到 AppLocker 策略
#   3. 再审计 1 周
```

### 步骤 8：切换到强制模式

```powershell
# 审计期间没有合法应用程序被阻断后：
# 将强制模式从"审计"更改为"强制"

# 更新 GPO：
# AppLocker → 可执行规则 → 属性 → 已配置：强制规则
# AppLocker → 脚本规则 → 属性 → 已配置：强制规则

# 分阶段强制执行：
# 第 1 周：仅强制 EXE 规则
# 第 2 周：强制脚本规则
# 第 3 周：强制 MSI 规则
# 第 4 周：（可选）强制 DLL 规则

# 持续监控：事件 ID 8004（已阻断 EXE）、8007（已阻断脚本）
```

## 关键概念

| 术语 | 定义 |
|------|------|
| **应用程序白名单** | 仅允许预先审批的应用程序执行、默认拒绝其他所有内容的安全模型 |
| **发布者规则** | 基于数字签名的 AppLocker 规则；对应用程序更新最具弹性 |
| **路径规则** | 基于文件系统路径的 AppLocker 规则；安全性较低，攻击者可将文件放置在允许的路径中 |
| **哈希规则** | 基于文件哈希的 AppLocker 规则；限制最严格，但每次应用程序更新都会失效 |
| **LOLBin** | Living Off the Land Binary；攻击者为规避检测而滥用的合法操作系统工具 |
| **审计模式** | AppLocker 记录策略违规但不阻断；对于规则优化至关重要 |
| **强制模式** | AppLocker 主动阻断违反策略规则的应用程序 |

## 工具与系统

- **AppLocker（内置）**：企业版/教育版 Windows 中的应用程序控制功能
- **WDAC（Windows Defender Application Control）**：AppLocker 面向现代 Windows 的更高级继任者
- **Microsoft LAPS**：管理本地管理员密码，防止通过管理员权限绕过 AppLocker
- **WDAC 向导**：用于创建 Windows Defender Application Control 策略的 GUI 工具
- **AaronLocker**：由 Microsoft 员工开发的开源 AppLocker 规则生成器（GitHub）

## 常见误区

- **跳过审计模式**：未经审计期直接在强制模式下部署 AppLocker 将阻断关键应用程序并导致中断。
- **仅依赖路径规则**：对允许路径（C:\Windows\Temp）有写入权限的用户可以绕过基于路径的规则。优先使用发布者规则。
- **未阻断用户可写目录**：最常见的缺口是允许从 %TEMP%、Downloads 或 %APPDATA% 执行。
- **忘记应用程序标识服务**：AppLocker 需要 AppIDSvc 服务运行。如果服务停止，所有规则都将停止强制执行。
- **管理员绕过**：本地管理员默认可以绕过 AppLocker。要实现完全强制，需结合 WDAC，后者对包括管理员在内的所有用户强制执行。
- **DLL 规则性能**：启用 DLL 规则会产生显著的性能开销。仅在高安全环境中启用，且需权衡利弊。