☰

Applocker 与软件限制策略

tag-icon • tag-icon windows-server-2008 security group-policy
Applocker 与软件限制策略

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

我读过很多来自微软和其他公司的文章，都说新的 Applocker 功能比旧的软件限制策略好 100%，建议用它来替代后者。

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

同时，它有一个很大的缺点，使它非常无用：它不可扩展，并且您不能添加想要限制的自定义文件扩展名。

Applocker 相对于 SRP 有哪些优势？您会推荐哪种软件控制方式？

答案1

Microsoft 已弃用软件限制策略（technet 声称不支持 SRP)，自从Windows 7 Enterprise/Ultimate引入了AppLocker。

实际上，SRP 存在某些缺陷，既有误报也有误报。AppLocker 的优势在于它仍在积极维护和支持。如果 AppLocker 是一个选项，那么它可能是更便宜的 - 考虑到你的时间和承担的风险。也可能有合适的第三方替代方案（但这个问题没有包括该选项 :)。

希望您能够在陷入任何 SRP 陷阱之前，充分了解这些陷阱</sarcasm>。其中一些陷阱在Vadims Podāns 撰写的精彩安全文章。

已知的陷阱

  1. 在里面默认规则，允许从\Windows文件夹执行。用户可以写入某些子文件夹。Applocker 相同，但至少官方文档提到了这个限制。

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

美国国家安全局的一份文件给出使用 SRP 列入黑名单的 16 个文件夹示例（尽管注册表路径规则错误地使用了反斜杠，因此必须进行更正 - 请参阅下面关于注册表路径的要点）并警告常见的过于宽泛的黑名单条目。

显而易见的问题是，为什么我们不仔细地将单个路径列入白名单呢\Windows？（包括\Windows\*.exe遗留系统System32\*.exe、等等）。我没有在任何地方看到对此问题的答案 :(。

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

务实的做法

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

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

  1. 从默认规则开始（从 Win7 之前的时代开始:)。
  2. 不想使用环境变量，例如%systemroot%。
  3. 添加规则以确保两个目录在现代 64 位机器上均被允许。在 64 位计算机上，\Program Files\您需要添加的额外“注册表路径”是和。\Program Files\%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
  4. 添加到注册表路径规则时，请删除百分号后面的所有反斜杠，并将其余的反斜杠替换\为正斜杠/（例如%HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe）
  5. 将 PS1 添加到受控扩展列表。
  6. 了解可管理的 SRP 配置对于决心破解它的用户来说并不安全。目的是帮助/鼓励用户遵守政策，保护他们免受“驱动下载”等攻击。
  7. 允许 LNK 文件。（最好将其从扩展列表中删除，而不是通过某些路径规则）。
  8. 参见第 7 点:)。
  9. 确保您的登录脚本文件夹已获准。NSA 文档建议添加\\%USERDNSDOMAIN%\Sysvol\。（参见第 2 点，唉，然后参见第 6 点）。

答案2

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

话虽如此，我看到了 AppLocker 的巨大好处（正如这个比较） 作为：

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

答案3

我在公司内部使用 Applocker。我们使用的策略是：拒绝一切作为基准（事实上：Applocker 默认），然后按照建议执行：制定一条规则，只允许签名的应用程序（office、adobe、wintools、ax 等）。大多数（也许所有）恶意软件都是未签名的软件，因此不会执行。几乎不需要任何维护。我只需要允许 3 个额外的旧版应用程序。

此外，我无法确认不能使用 UNC 路径。在一些额外的安全拒绝规则中，我成功使用了 UNC 路径。陷阱在于使用环境变量：它们不适用于 Applocker。使用 * 通配符。我在 Windows 2008 R2 和 Windows 2012 R2 上使用它。

我非常喜欢它：几乎没有任何性能下降。正如文档所述：Applocker 依赖于应用程序标识服务（确保它自动启动）。

答案4

AppLocker 没有任何好处，微软发表了赤裸裸的谎言：1. 具有 SAFER 规则的 GPO 可以附加到用户和用户组；2. Windows Vista 引入了多个本地 GPO，无需域控制器即可实现相同的结果；3. 审计模式可通过扩展日志记录功能使用，无需强制执行。

相关内容