Applocker 与软件限制策略

Question

目标是防止用户在终端服务器上运行不需要的程序。

我读过很多来自微软和其他人的文章，他们说新的 Applocker 功能比旧的软件限制策略好 100%，建议作为后者的替代品。

除了内核模式执行之外，我不确定是否了解 Applocker 的真正优势。它的大部分功能都可以通过软件限制策略进行复制。

同时，它有一个很大的缺点，使它变得毫无用处：它不可扩展，并且您无法添加要限制的自定义文件扩展名。

Applocker 相对于 SRP 的优势是什么？您对软件控制有什么建议？

Answer 1

由于 Windows 7 Enterprise/Ultimate 引入了 AppLocker ，Microsoft 已弃用软件限制策略（technet 有效地声称不支持 SRP）。

在实践中，SRP 有一定的缺陷，包括假阴性和假阳性。AppLocker 的优势在于它仍在积极维护和支持。如果 AppLocker 是一种选择，那么在考虑到您的时间和所承担的风险之后，它可能是更便宜的选择。也可能有合适的第三方替代方案（但这个问题不包括该选项：）。

希望您在陷入其中任何一个陷阱之前，已完全了解 SRP 的陷阱</sarcasm>。其中一些在来自 Vadims Pod?ns 的一篇不错的安全文章中有所描述。

已知的陷阱

1. 在默认规则中，\Windows允许从文件夹执行。一些子文件夹可以由用户写入。Applocker 是一样的，但至少官方文档提到了这个限制。

“要枚举具有用户写访问权限的所有文件夹，您可以使用，例如，Sysinternals 包中的 AccessEnum 实用程序。” （或AccessChk）。

一份 NSA 文档提供了16 个使用 SRP 列入黑名单的文件夹示例（尽管注册表路径规则错误地使用了反斜杠，因此必须更正 - 请参阅下面的注册表路径点）并警告常见的黑名单条目过宽。

显而易见的问题是，为什么我们不小心地将各个路径列入白名单\Windows。（包括\Windows\*.exe遗产System32\*.exe、 等）。我在任何地方都没有注意到任何答案:(。

2. 使用环境变量，如%systemroot%，用户可以通过清除环境变量来绕过 SRP。这些不用于建议的默认值。然而，他们可能很想使用。这个footgun 在AppLocker 中是固定的，因为它从不查看环境变量。
3. 建议的默认值忽略了\Program Files在现代 64 位安装中使用的两种不同。当使用更安全的“注册路径”解决这个问题时，随机情况下会出现错误拒绝的报告，这在测试中很容易被遗漏。例如，请参阅SpiceWorks SRP howto上的评论。这与 32 位应用程序从注册表的 WOW6432Node 读取相关路径有关：解决方案是将这两个路径都添加到 SRP 中，以允许所有程序在 32 位和 64 位机器上运行不受限制，无论是否从 x64 启动或 x86 主机进程：%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
4. 默认扩展忽略禁止 Windows 支持的 PowerShell 脚本 (*.PS1)。（见视频）。还有APPX。同样根据微软的对比表，SRP 无法在 Windows 8 中管理“Packaged apps”；我不知道这是什么意思。
5. 注册表路径规则在最后一个百分号之后不能有斜线（尽管包含在 Microsoft 自己的 XP/Server 2003 内置规则中）并且任何反斜线都必须替换为正斜线才能使规则起作用（1 / 2 / 3）。
6. 在我为 SRP 找到的来源中，没有一个将上面的完整列表放在一起。我只是偶然发现了 Vadims Pod?ns 的文章。 外面还潜伏着什么？
7. 许多来源建议简单地从列表中删除 LNK 文件。（还有避免破坏收藏夹的网络快捷方式？！）。令人不安的是，似乎没有消息来源讨论 LNK 漏洞……或者让脚本解释器运行具有意外扩展名的文件，例如wscript /e……或者可能在内联脚本参数中填充足够的 shellcode……等等。
8. 如果您试图通过允许桌面上的 LNK 文件来妥协，并且您让用户拥有桌面的写访问权限，他们现在可以完全绕过您的策略。再次来自 Vadims Pod?ns 的可爱提示。请注意，该说明适用于在路径规则中使用任何扩展名。Microsoft*.Extension在没有警告的情况下提供了多个示例，包括。所以你不能相信官方文档，现在似乎不太可能得到修复。
9. [潜在的 AppLocker 缺点]。Vadims Pod?ns 报告使用映射驱动器的 SRP 条目不起作用。必须改用 UNC 路径。也许他们会申请通过映射驱动器进行访问？这不是 100% 清楚。显然 AppLocker 是不同的：它不适用于 :(。 “由于未知原因，UNC 路径在 Applocker 中不起作用！这意味着如果您的应用程序安装在网络中，您必须创建哈希或发布者规则.”

务实的方法

软件白名单可能是一种非常强大的防御措施。如果我们变得愤世嫉俗：这正是微软弃用低价版本并发明更复杂版本的原因。

也许没有其他选项可用（包括第 3 方解决方案）。那么一种务实的方法是尝试尽可能简单地配置 SRP。将其视为具有已知漏洞的额外防御层。匹配上面的陷阱：

1. 从默认规则开始（从前 Win7 时代开始：）。
2. 最好不要使用环境变量，例如%systemroot%.
3. 添加规则以确保\Program Files\在现代 64 位机器上允许这两个目录。您需要\Program Files\在 64 位计算机上添加的额外“注册表路径”是%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%和%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%。
4. 当添加到注册表路径规则，遗漏任何反斜杠百分号后，并更换任何进一步的反斜杠\与forwardslashes /（例如%HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe）
5. 将 PS1 添加到受控扩展列表中。
6. 了解可管理的 SRP 配置对于决心打败它的用户来说是不安全的。目的是帮助/鼓励用户在政策范围内工作，保护他们免受“偷渡式下载”等攻击。
7. 允许 LNK 文件。（最好是从扩展列表中删除它，而不是通过一些路径规则）。
8. 见第 7 点 :)。
9. 确保您的登录脚本文件夹被允许。NSA 文件建议添加\\%USERDNSDOMAIN%\Sysvol\. （见第 2 点，叹气，然后见第 6 点）。

Answer 2

我同意 SRP 有一些 AppLocker 真正可以从中受益的附加功能。

话虽这么说，我认为 AppLocker 的巨大优势（如本次比较所述）为：

• AppLocker 规则可以针对特定用户或一组用户，而 SRP 则在整个计算机上强制执行。
• AppLocker 支持审核模式，以便规则可以在强制执行之前在生产中进行测试。SRP 没有等效的仅日志模式。